Persistencia encubierta en Linux: Velvet Ant modifica PAM y OpenSSH para capturar credenciales

Un actor vinculado a China conocido por investigadores como Velvet Ant ha llevado la persistencia a un nuevo nivel: en lugar de esconderse en software nuevo o herramientas propias, ha modificado los propios programas que deciden quién entra en los sistemas Linux. Según los análisis públicos y la trayectoria del grupo, el adversario llegó a reemplazar componentes críticos del sistema de autenticación —PAM y OpenSSH— con versiones maliciosas que registraban credenciales y comandos, o que aceptaban contraseñas ocultas; trabajo sigiloso que puede pasar por administración legítima durante años.

La técnica es doblemente peligrosa: primero porque ataca el punto más confiable del host —el que valida identidades— y segundo porque el objetivo era, en muchos casos, redes aisladas sin acceso directo a Internet. Para llegar hasta allí los atacantes usaron sistemas expuestos como puente y herramientas disfrazadas que retransmitían órdenes hacia el segmento “air-gapped”. Ese enfoque paciente y modular se parece a las campañas previas del mismo actor, que han usado dispositivos de infraestructura como F5 BIG‑IP o switches Cisco NX‑OS como plataformas internas de comando y control.

Las implicaciones operativas son claras: los procedimientos estándar de contención, como cerrar sesiones o forzar el cambio de contraseñas, pueden ser ineficaces si la pieza que valida esas credenciales resulta estar comprometida. Resetear claves sin antes verificar y limpiar la cadena de autenticación deja una puerta abierta para que las nuevas credenciales sean capturadas y exfiltradas.

Desde el punto de vista defensivo, la primera lección es trasladar la vigilancia hacia donde tradicionalmente no se mira. Monitoreo de integridad de archivos para los binarios de login (por ejemplo /usr/sbin/sshd y los módulos de PAM en /lib/security o /lib64/security según la distribución) debe estar en la lista prioritaria. Además de alertas en tiempo real conviene implementar caza activa: comparar hashes de los ejecutables con copias conocidas y firmadas por el proveedor, y verificar la integridad del paquete usando herramientas del propio gestor de paquetes (rpm -V, debsums u otras alternativas según la distro).

Las acciones de remediación requieren cautela. No sustituya ni reinicie a ciegas un binario de autenticación en producción; una copia incorrecta puede bloquear administradores y complicar la recuperación. El flujo razonable es aislar el equipo, arrancar desde un medio de rescate (live CD/USB) para obtener un entorno de confianza, verificar y reemplazar los binarios con artefactos firmados o construidos en un entorno de CI seguro, y solo entonces rotar credenciales y claves. Probar cualquier reemplazo en laboratorios reproducibles antes de aplicar en producción reduce el riesgo de errores fatales.

La higiene complementaria que reduce la ventana de abuso incluye limitar al mínimo los servicios y cuentas con privilegios de administración, forzar autenticación multifactor para accesos críticos y preferir autenticación basada en claves y agentes con protección de hardware cuando sea posible. También hay que auditar y bloquear canales de retransmisión inusuales: revisar servidores web expuestos que puedan actuar como puente y supervisar conexiones salientes inesperadas desde appliances de red y balanceadores.

En el caso concreto de las vulnerabilidades usadas previamente por este actor, los equipos deben asegurarse de aplicar los parches y mitigaciones recomendadas por los fabricantes y por autoridades de seguridad. Las organizaciones pueden consultar avisos y guías oficiales para confirmar la exposición de su infraestructura; recursos públicos como CISA o los informes de firmas de respuesta a incidentes como Sygnia ofrecen contexto técnico y pasos de mitigación útiles. Para entender mejor los componentes atacados y cómo protegerlos, conviene revisar también las fuentes originales del software como OpenSSH y Linux-PAM.

Finalmente, la lección estratégica es que la confianza por defecto en la infraestructura debe reemplazarse por verificación continua. Componentes que históricamente se consideraron estables y “siempre correctos” —balanceadores, switches, y especialmente el propio login— son ahora objetivos de persistencia. La defensa eficaz exige integrar controles de integridad en la supervisión cotidiana, políticas de recuperación que contemplen arranques desde medios de confianza, y ejercicios de caza de amenazas que comprueben cambios en artefactos críticos antes de asumir que un restablecimiento de credenciales cierra el incidente.