Durante 10 años introducías tu contraseña y un hacker la leía en tiempo rea

Durante casi diez años, el mismo atacante accedió a una red aislada sin salida directa a internet. No por una puerta abierta ni por un VPN accidental, sino por una cadena de servidores externos comprometidos, túneles, componentes SSH sustituidos y puertas traseras en el propio sistema de autenticación. Sygnia descrió la operación llamada Operation Highland y la vinculó con el grupo Velvet Ant, que la empresa clasifica como actores con nexos en China.

La investigación se presenta como el análisis de un incidente casi rutinario, pero las primeras señales de actividad llevaron a los especialistas hasta 2016. Y pronto quedó claro que no se trataba de un ataque menor y reciente, sino de una presencia de años dentro de la red interna. Lo más preocupante era que el segmento objetivo no tenía conexión directa a internet. El aislamiento no lo evitó: los atacantes construyeron una ruta a través de sistemas externos, luego atravesaron la red de TI y llegaron a la infraestructura crítica.

Velvet Ant ya había aparecido en informes anteriores de Sygnia. En distintas investigaciones el grupo utilizó F5 BIG-IP, servidores Windows antiguos y Cisco Nexus. En un caso explotó la vulnerabilidad CVE-2024-20399 en Cisco NX-OS e instaló un backdoor VELVETSHELL directamente en los conmutadores de red. El comportamiento en Operation Highland encaja en el mismo estilo: si encuentran un punto de acceso, los atacantes avanzan hacia capas menos visibles de la infraestructura y se establecen allí de nuevo.

En la primera fase el grupo obtuvo acceso persistente a servidores expuestos a internet. Para la ejecución remota de comandos se utilizó una versión modificada de GS-Netcat, una herramienta del Global Socket Toolkit. Esta herramienta puede levantar una shell inversa cifrada y encaminar el tráfico a través de la Global Socket Relay Network. En el entorno comprometido el archivo se llamó auditdb y lo colocaron en /usr/sbin/ para que pareciera una utilidad del sistema.

Dentro de ese binario estaba incrustado un dominio del tipo %.gs.thc[.]org, asociado con la infraestructura de The Hacker's Choice y, probablemente, con la red relay de GS-Netcat. Para no destacarse en la lista de procesos, el programa sustituyó su propio argv[0] por [khubd], haciéndose pasar por un hilo del núcleo de Linux. Para el arranque automático emplearon distintos trucos: en servidores nuevos crearon una unidad systemd disfrazada de servicio Chrome, y en sistemas antiguos añadieron la línea de arranque a los scripts de /etc/init.d/.

Paralelamente Velvet Ant instaló un proxy SOCKS5 en Perl. Funcionaba como demonio en segundo plano, aceptaba conexiones en un puerto determinado y reenviaba el tráfico a través de máquinas ya comprometidas. Sygnia determinó que el script era una versión modificada del proyecto público ssspl. Para ocultarlo, el proceso se llamaba smbd -D, como si perteneciera a Samba. En distintas muestras variaban el nombre del archivo, el puerto y el nombre del proceso, por lo que relacionarlas entre sí resultaba más difícil.

Tras asentarse en los sistemas externos el grupo construyó un camino hacia el segmento cerrado. Una de las entradas pasaba por Nginx. En el servidor accesible desde internet modificaron la configuración para que las peticiones a una URL concreta se proxyen a un servidor interno. El Nginx interno, a su vez, reenviaba las peticiones al proceso FastCGI fcgiwrap, que ejecutaba un archivo con el aparentemente inocuo nombre uptime.

Ese uptime no era la utilidad del sistema habitual. La herramienta establecía una conexión SSH con un servidor en la red de infraestructura crítica, usando parámetros del cuerpo de una petición HTTP POST. Tras la conexión ejecutaba un script en el equipo objetivo y permitía obtener datos confidenciales. En consecuencia, una simple petición HTTP al servidor web externo se convertía en ejecución remota de comandos dentro del segmento aislado.

El núcleo del ataque fue más profundo. Velvet Ant no se limitó a puertas traseras y túneles individuales. El grupo sustituyó componentes por los que los administradores acceden a servidores Linux: PAM y OpenSSH. PAM se encarga de verificar credenciales, y OpenSSH proporciona acceso remoto, copia de archivos y ejecución de sesiones. Si el atacante controla esa capa, un cambio ordinario de contraseñas ya no soluciona el problema: las nuevas credenciales pueden ser interceptadas de nuevo en el siguiente acceso.

Sygnia encontró nueve variantes maliciosas de pam_unix.so. El módulo PAM legítimo se reemplazaba por bibliotecas modificadas en las que se alteraba la función pam_sm_authenticate. En su funcionamiento normal esta función recibe el login y la contraseña, los verifica y devuelve éxito o fallo. En la versión con puerta trasera la función podía aceptar una contraseña incrustada del atacante, recopilar las credenciales de usuarios reales o combinar ambos mecanismos.

En algunas variantes existía solo una forma de eludir la autenticación: al introducir una contraseña especial el módulo dejaba pasar al atacante sin la comprobación estándar. Tras el acceso exitoso la cadena con la contraseña del backdoor se sobreescribía en memoria con ceros para dificultar el análisis. En otra variante se usaba la contraseña cifrada Pamauth@123456, y todos los nombres de usuario y contraseñas ajenos se escribían en un archivo oculto /usr/sbin/.ssh.log. En algunos casos los registros además se limpiaban de duplicados.

Las nueve variantes de pam_unix.so se compilaron en distintos entornos. Lo indicaban RPATH diferentes, es decir, rutas donde el cargador busca las bibliotecas durante la ejecución. Sygnia interpreta ese patrón como señal de compilaciones pensadas para distintos objetivos, no como un conjunto accidental de archivos.

OpenSSH también quedó bajo control de los atacantes. En las variantes más recientes se modificaron ssh, sshd, ssh-keygen y scp, aunque las funciones maliciosas se encontraron en tres de ellos: ssh, sshd y scp. Los ssh y sshd modificados interceptaban credenciales en conexiones entrantes y salientes, las cifraban y las guardaban en /usr/share/man9/ph/.ph.man. En cada registro quedaban anotados el sentido de la conexión, el tipo de autenticación y el resultado del acceso.

Aparte de las contraseñas, los binarios modificados registraban los comandos que el usuario introducida en la shell. sshd generaba registros cifrados con datos sobre el usuario, el TTY, la duración de la sesión y la dirección IP. ssh hacía una anotación similar para las conexiones salientes. Para los archivos en /usr/share/man9/ph/ aplicaron timestomping: las marcas temporales se ajustaban a la fecha de /etc/shells para ocultar la aparición de nuevos artefactos en la cronología del sistema de archivos.

Los atacantes incluso se protegían de su propia vigilancia. En el ssh modificado añadieron la opción -d, que desactivaba el registro de contraseñas y comandos. Velvet Ant podía operar mediante herramientas comprometidas sin dejar rastros de su propia actividad. Es un detalle importante: la puerta trasera no solo permitía el acceso, sino también un trabajo discreto dentro del entorno ya comprometido.

scp obtuvo funciones adicionales. Al ejecutarse como root, el scp malicioso podía desactivar SELinux para eliminar las restricciones de control de acceso obligatorio y así leer o transferir archivos con mayor libertad. Otra opción especial, "!", cambiaba el nombre del proceso a [kauditd] -sh, imitando un demonio legítimo de auditoría de Linux.

Sygnia también encontró una rama antigua de OpenSSH modificada. En esa rama solo se alteraban ssh y sshd. El backdoor en sshd operaba mediante hashes: la contraseña introducida se interceptaba, se hasheaba y se comparaba con un valor incrustado. Además del hash general, en el binario había siete MD5 separados, uno para cada día de la semana. Los registros de credenciales en la versión antigua se escribían en /usr/lib/eth-scsi/libethscsi.so, y los comandos en /var/lib/sam/ con nombres del tipo sam_{timestamp}. Fue mediante esos archivos que Sygnia detectó las primeras señales de keylogging que se remontan a 2016.

Otro nivel de acceso era más sencillo: los atacantes añadían sus claves SSH públicas en authorized_keys de los servidores comprometidos. Por supuesto, no es tan sofisticado como sustituir PAM o OpenSSH, pero proporciona un acceso persistente sin contraseña y funciona independientemente de los binarios maliciosos.

La limpieza de la red resultó arriesgada. Cuando un servicio normal está infectado, se puede detener, eliminar y reemplazar. Cuando PAM y OpenSSH han sido sustituidos, un reemplazo imprudente puede dejar a los administradores bloqueados fuera. En infraestructura crítica, cualquier error de ese tipo convierte la respuesta a un incidente en una paralización de la producción.

El aislamiento complicaba la situación: la mayoría de los sistemas no tenía acceso a internet, por lo que no era posible simplemente descargar paquetes limpios desde los repositorios y resolver dependencias. En el entorno se usaban distintas versiones de Linux, bibliotecas diversas y compilaciones diferentes de PAM y OpenSSH. Un componente seguro para un host podía romper el acceso en otro.

¿Cómo se llevó a cabo la recuperación? Primero se preparó un laboratorio donde se probó el proceso de reemplazo. Luego, para cada host se determinaban los componentes limpios adecuados, se transferían a la red cerrada de forma controlada, se realizaba el reemplazo y se verificaban enseguida SSH y la autenticación. Se prepararon planes de reversión por anticipado, y la comprobación del acceso se consideró parte de la recuperación, no una formalidad final.

La lección principal de Operation Highland es inquietante para cualquier red aislada. La ausencia de una salida directa a internet cambia la ruta del atacante, pero no hace imposible la compromisión. Velvet Ant pasó a través de servidores externos, empleó proxies y una cadena web, y luego se fijó en el propio mecanismo de acceso. En tal situación, los registros de acceso pueden parecer normales, los comandos se introducen mediante herramientas habituales y el atacante se mueve como un administrador.

Sygnia recomienda considerar PAM, OpenSSH, LSASS y otros componentes de autenticación como controles de seguridad críticos, no como simples archivos del sistema. Para servidores Linux es importante monitorizar cambios en pam_unix.so, en las configuraciones de /etc/pam.d/, en ssh, sshd, scp, sftp, ssh-keygen, sshd_config, authorized_keys, en archivos de unidades systemd y en scripts SysVinit. Para Windows se requiere un enfoque similar con LSASS y los componentes de LSA, porque ataques de tipo Skeleton Key también intervienen en el propio proceso de verificación de credenciales.

Una recomendación práctica aparte concierne al cambio de contraseñas. Hacerlo antes de eliminar las puertas traseras es peligroso: las nuevas credenciales pueden registrarse de inmediato en los registros de PAM o SSH sustituidos. Primero hay que restaurar la confianza en el mecanismo de acceso, eliminar los componentes maliciosos, verificar el acceso y solo entonces cambiar las contraseñas.