La mentira de la «licencia compartida»

Cómo una red de piratería de paneles de control utiliza una ficticia «licencia corporativa compartida» para legitimar puertas traseras encubiertas en los sistemas de Clientes que pagan.

En un párrafo

Un actor vende licencias baratas de cPanel/WHM y CloudLinux haciendo pasar el servidor de cada Cliente por una única «licencia corporativa compartida» que el actor controla. Para que ese encaminamiento funcione, el actor instala acceso administrativo persistente — módulos Perl modificados, llamadas periódicas a hosts del actor, binarios de validación reemplazados, tareas cron ocultas — en todos los sistemas Cliente. El Cliente cree haber conseguido una ganga. En realidad ha pagado para que un atacante conserve root en su servidor. Meses después, cuando el Cliente deja de pagar o protesta, ese mismo acceso se monetiza: robo de datos, ransomware o extorsión. Este documento describe el patrón, los indicadores y cómo desalojar el acceso de forma limpia.

1. Resumen ejecutivo

Desde hace al menos tres años, un colectivo informal de operadores anuncia licencias «gratuitas» o muy rebajadas de cPanel/WHM y CloudLinux/Imunify a pequeños hosters, MSPs y sysadmins individuales. La oferta se presenta como una «licencia corporativa compartida» o «pool de revendedor» que, supuestamente, permite a varios servidores apoyarse en un único contrato empresarial legítimo.

La oferta es mentira. El modelo de licencia de cPanel y CloudLinux no permite que una sola licencia cubra válidamente servidores de terceros no relacionados. La «compartición» funciona únicamente porque el operador instala un agente activo de gestión en cada servidor Cliente, agente que extrae periódicamente una falsa confirmación de licencia de infraestructura bajo control del operador. Ese agente es una puerta trasera bajo cualquier definición razonable: concede al operador acceso privilegiado persistente al sistema del Cliente.

SOMA9 ha observado y extirpado este patrón de acceso en servidores adquiridos durante traspasos operativos. El presente documento publica los indicadores, la lógica de detección y el procedimiento de desalojo para que otros hosters y administradores puedan verificar sus propios sistemas y eliminar el acceso si lo encuentran.

2. El gancho

El patrón es consistente entre nombres de operador, marcas y empresas pantalla:

• Canal. Telegram, Discord y pequeños foros privados. A veces un sitio web con apariencia profesional. Casi nunca canales tradicionales (sin LinkedIn, sin Trustpilot, sin GitHub público).
• Precio. Un tercio o menos del precio mensual oficial de cPanel/CloudLinux para el equivalente. A menudo, pago único de por vida a un precio que ni siquiera amortiza el coste oficial aguas arriba en cualquier escenario razonable.
• Justificación. El operador alega disponer de un contrato empresarial y poder «compartirlo» entre Clientes. Variantes: programa de socios de hosting, esquema de re-licenciamiento, sobrante de un negocio cerrado, acuerdo académico.
• Onboarding. El operador solicita acceso SSH «para instalar la licencia». Se ejecuta un script breve. El panel se pone en verde. El Cliente disfruta un año de operación barata.

3. El mecanismo

El script entregado durante el onboarding hace varias cosas en una sola pasada:

1. Sustituye el módulo de validación de licencia del panel por una versión modificada que devuelve éxito al ser invocada, ignorando la ausencia de licencia real aguas arriba. Objetivos típicos: módulos Perl en /usr/local/cpanel/Cpanel/License.pm, binario en /usr/local/cpanel/cpkeyclt o equivalentes en CloudLinux.
2. Instala un watchdog persistente, normalmente un script shell o Perl registrado como tarea cron o timer de systemd. El watchdog hace una llamada periódica — típicamente cada cinco a quince minutos — a un dominio operado por el operador. La llamada lleva un identificador del servidor y una marca temporal; la respuesta puede contener un token de confirmación (de modo que la validación modificada siga «teniendo éxito») o una orden arbitraria a ejecutar.
3. Almacena en caché la programación de las llamadas en lugares poco visibles a simple vista: archivos ocultos en /etc o /var, drop-ins de anacron, dotfiles en directorios de usuarios no root y, en ocasiones, en imágenes de initramfs para que un reinicio no las pierda.
4. Planta un canal de respaldo. Si el dominio principal de llamada se desactiva, el watchdog puede resolver vía un dominio de reserva codificado, una URL de pastebin o un registro DNS TXT.
5. Opcionalmente añade una clave SSH a /root/.ssh/authorized_keys o a una cuenta sin privilegios con sudo. Algunas variantes prefieren el canal de comandos del watchdog y prescinden de esto.

El operador presenta el paso 1 como «la instalación de la licencia» y minimiza el resto. El Cliente rara vez audita.

4. Por qué «compartir licencia» es imposible por diseño

Las licencias de cPanel están vinculadas a una dirección IP. Cada ejecución de cpkeyclt valida la IP licenciada contra el servidor aguas arriba. No existe mecanismo documentado por el cual una sola licencia valide simultáneamente dos IPs no relacionadas, por diseño. Existen restricciones equivalentes para CloudLinux e Imunify.

Por tanto, todo arreglo que aparente compartir una licencia entre servidores de Clientes no relacionados está haciendo necesariamente alguna de las siguientes cosas:

• Falsificar la validación localmente — modificando el módulo de validación para que devuelva éxito sea cual sea la respuesta aguas arriba.
• Proxificar la validación — interceptando el tráfico de cpkeyclt del Cliente y respondiéndolo desde infraestructura del operador.
• Rotar IPs — cambiando brevemente la IP licenciada en el momento de la validación. Frágil y poco frecuente en la práctica.

Las tres requieren acceso persistente y privilegiado en el servidor del Cliente. No hay cuarta opción. La «licencia compartida» que se anuncia no existe.

5. Indicadores de compromiso

Los siguientes indicadores son genéricos a las distintas variantes del operador. Los nombres de archivo, dominios e indicadores de red específicos se publicarán en un feed legible por máquina que acompaña a este documento en soma9.cloud/threat-intel/shared-license-lie/iocs.json y se rotarán a medida que aparezcan nuevas variantes.

5.1 Sistema de archivos

• Módulo Perl modificado: /usr/local/cpanel/Cpanel/License.pm con hashes que se desvían del paquete oficial cPanel. Verificar con rpm -V cpanel en sistemas RHEL o md5sum contra una copia limpia del mismo build.
• Binario cpkeyclt sustituido o envuelto: el binario en /usr/local/cpanel/cpkeyclt es un wrapper shell, o el tamaño difiere materialmente del build oficial.
• Archivos ocultos de caché de licencia en ubicaciones inusuales: /etc/.cache/lic*, /var/lib/.cpanel-lic-cache, dotfiles en /root/ con referencias a validación de licencia.
• Script watchdog con nombres tipo license-keepalive, cl-renew, panel-sync, watchdog.sh; ubicado en /usr/local/sbin, /opt o /root.
• Claves SSH anómalas en /root/.ssh/authorized_keys o en el ~/.ssh/authorized_keys de cualquier usuario, con campos comentario que mencionan licencia/panel/sync.

5.2 Procesos y red

• HTTPS saliente periódico desde cron o systemd-timers hacia dominios pequeños sin categoría conocida, con intervalo fijo (cada 5 / 10 / 15 minutos).
• Consultas DNS TXT salientes a dominios que no formen parte de la telemetría legítima de plataforma, en particular cuando coincidan con la cadencia del cron del watchdog.
• Utilidades capaces de reverse-shell (nc, socat, bash -i) apareciendo en árboles de proceso lanzados por el watchdog.

5.3 Cron y planificador

• Entradas en /etc/cron.d/, /etc/crontab, /var/spool/cron/root o systemd-timers de root que referencien al watchdog.
• Drop-ins de anacron (/etc/anacrontab, /etc/cron.daily/) utilizados para reinstalar el watchdog cuando se elimina.
• Líneas de tarea que canalizan a /dev/null 2>&1 sin contexto de log alguno.

6. Reglas de detección

Detectarlo es directo cuando se busca explícitamente. Dos consultas en capas cubren la mayor parte de variantes:

# 1. Verificar la integridad del paquete cPanel
rpm -V cpanel | grep -E '(License\.pm|cpkeyclt)'
# 5 columnas: missing/size/mtime/md5/group; salida limpia es vacía.

# 2. Buscar HTTPS saliente periódico no iniciado por un servicio conocido
ss -tnp state established 'dport = 443' | awk '{print $5,$6}' \
  | grep -vE 'cpanel\.net|cloudlinux\.com|imunify\.com|known-update-mirror'

# 3. Auditar entradas cron con llamadas de alta frecuencia
grep -rE '^\*/(5|10|15) ' /etc/cron.d /etc/crontab /var/spool/cron 2>/dev/null

# 4. Buscar ubicaciones ocultas de caché
find /etc /var /root -maxdepth 3 -name '.*lic*' -o -name '.*panel*' -o -name '.*key*' 2>/dev/null \
  | grep -E '\.(cache|hidden|private)'

# 5. Comparar el hash de License.pm con el oficial
sha256sum /usr/local/cpanel/Cpanel/License.pm
# Compárese con el hash del build de cPanel publicado en las release notes oficiales.

SOMA9 publica reglas YARA mantenidas y un script detector ampliado en el repositorio de código abierto SOMA9-Cloud, dentro del proyecto wp-shell-hunter, ampliado con detectores de panel de control.

7. Procedimiento de desalojo

El desalojo debe realizarse en este orden. Saltarse pasos reintroduce el acceso.

1. Tomar una instantánea del sistema con fines forenses si todavía no se ha hecho. Antes de cualquier acción destructiva.
2. Cortar primero el acceso de red del operador. Bloquear el dominio de llamada del watchdog en la salida; no apoyarse en iptables del propio host que el operador puede controlar. Bloquear en el firewall aguas arriba.
3. Desactivar el watchdog retirando la entrada cron / la unidad systemd-timer y matando el proceso en ejecución. Verificar que no se reactiva (las variantes habituales tienen una tarea de respawn separada; eliminar también ésa).
4. Restaurar los binarios del panel desde el paquete oficial: yum reinstall cpanel o el equivalente de la plataforma. Verificar con rpm -V cpanel.
5. Rotar todas las credenciales. Contraseña de root, claves SSH de todos los usuarios (eliminar antes, recrear tras el desalojo), tokens de API, contraseñas de cuentas de correo en cuentas que se sospecha hayan sido tocadas, contraseñas de bases de datos correspondientes, contraseñas de admin del panel. Asumir que cualquier credencial expuesta mientras el watchdog estuvo activo está filtrada.
6. Re-licenciar de forma legítima. Adquirir licencia real de cPanel y CloudLinux bajo contrato propio. Ejecutar /usr/local/cpanel/cpkeyclt desde un estado limpio. La diferencia de precio frente a la «licencia compartida» se recupera tras el primer intento de extorsión.
7. Realizar un escaneo completo de malware en las cuentas de Clientes. El mismo acceso utilizado para mantener la licencia falsa se usa rutinariamente para depositar malware secundario. Imunify360 con PROACTIVE_DEFENCE en modo KILL detecta la mayoría de los stages secundarios observados; ClamAV con firmas al día detecta otra parte.
8. Auditar los registros de autenticación y de correo saliente de los últimos 30 días para identificar todo aquello que pudiera haberse hecho con el acceso mientras estuvo activo.

8. Endurecimiento para evitar reentradas

• Aplicar el atributo inmutable (chattr +i) a los módulos de validación de licencia del panel tras restaurarlos al contenido oficial. Esto impide que un watchdog reinstalado los modifique en silencio.
• Configurar monitorización de integridad de archivos para alertar ante cambios en /usr/local/cpanel/Cpanel/License.pm, /usr/local/cpanel/cpkeyclt y los equivalentes de CloudLinux/Imunify.
• Restringir el HTTPS saliente en el firewall de salida a una lista de destinos conocidos: mirrors de actualización del fabricante del panel, repositorios de paquetes y la propia monitorización. Cualquier destino fuera de la lista se bloquea y registra.
• Deshabilitar SSH como root; exigir usuarios nominados con sudo. Mantener el authorized_keys de root vacío.
• Negarse a otorgar acceso SSH a cualquier tercero que solicite acceso «para instalar una licencia». Una instalación legítima de licencia no requiere shell de tercero.

9. Si lee esto porque fue Cliente

No es la primera persona a la que le pasa y no está en problemas por haber sido el Cliente. Los operadores apuntan a sysadmins técnicamente competentes a los que les vendieron una historia bien armada. Este documento existe para que pueda mirar, encontrar y eliminar. Si tras leerlo desea una segunda opinión antes de actuar, escriba a security@soma9.cloud; ayudaremos con el desalojo sin coste. Si sus servidores fueron origen de abuso de correo, fraude o ataques contra terceros mientras este acceso estuvo activo, escriba a abuse@soma9.cloud y le ayudaremos a procesar la limpieza.

10. Reportes

Si ha observado una variante reciente, un nuevo operador, un nuevo dominio o un nuevo patrón de sistema de archivos consistente con este tradecraft, repórtelo:

• Correo: threat-intel@soma9.cloud
• Cifrado PGP: soma9.cloud/.well-known/pgp.txt
• Se aceptan reportes anónimos.

Los reportes que conduzcan a la publicación de una variante o a una retirada reciben mención en el Hall of Fame de SOMA9 si el reportante consiente.