La puerta abierta por OpenSSH y Tailscale la intrusión que persiste cuando falla el C2

Un intruso francófono identificado por los investigadores como "Poisson" comprometió una pequeña empresa automotriz en Francia con técnicas que, en la superficie, parecen rutinarias: keylogger, robo de credenciales bancarias y acceso remoto. Lo que convierte este caso en una lección para operadores y defensores no es tanto la herramienta usada, sino la decisión del atacante de crear una puerta de retorno que no dependía de su servidor de comando y control (C2). El análisis pormenorizado lo publicó Cato Networks y ofrece una reproducción casi minuto a minuto de la operación desde el teclado del propio atacante: un registro ideal para quienes buscan entender cómo se construyen y mantienen accesos persistentes en entornos de bajo presupuesto. Informe de Cato CTRL documenta cómo una serie de comandos aparentemente anodinos cristalizaron en acceso continuado, incluso cuando la infraestructura de Havoc (el C2) quedó fuera de servicio.

La maniobra crítica fue la instalación de OpenSSH y de Tailscale en un equipo Windows, la configuración de autenticación por clave y un túnel reverso SSH. En la práctica, eso creó una malla cifrada y privada del atacante hacia la máquina afectada, evitó exponer puertos y, sobre todo, hizo que la puerta permaneciera abierta aun cuando el C2 tradicional falló. Apagar el servidor de comando y control no bastó; la persistencia se había transferido a un canal legítimo y cifrado. Tailscale es un servicio legítimo y ampliamente usado para redes privadas sobre Internet, lo cual resalta el problema: herramientas legítimas pueden ser explotadas para continuidad operativa maliciosa. Más información sobre Tailscale y su modelo se encuentra en su web oficial: https://tailscale.com/.

El caso también muestra el uso deliberado de técnicas de bajo rastro: la carga útil de Havoc se ejecutó casi totalmente en memoria mediante un loader en .NET iniciado por PowerShell, y las credenciales fueron recolectadas con un keylogger en Python que simplemente escribía localmente y era recuperado "a mano" por el operador. La ausencia de exfiltración directa a un servidor público y la preferencia por canales legítimos reducen las señales tradicionales que disparan detecciones basadas en IoC (indicadores estáticos). Además, el operador aprovechó herramientas firmadas y clientes remotos legítimos como RustDesk, lo que hace que la detección basada solo en hashes o nombres de archivo falle con facilidad.

Para defensores, la lección operativa es clara: tratar un C2 derribado como fin de la intrusión es un peligroso espejismo. La respuesta debe pivotar rápido de "apagar la infraestructura externa" a "buscar puertas internas alternativas". Eso implica auditar servicios instalados, revisar claves SSH y redes privadas configuradas, y verificar tareas programadas y persistencias en memoria. Microsoft mantiene documentación sobre la funcionalidad OpenSSH en Windows que puede servir de referente a equipos de respuesta para identificar instalaciones legítimas versus sospechosas: https://learn.microsoft.com/.

En términos prácticos y accionables, conviene prestar atención a varios signos que el atacante dejó de forma repetida: la presencia de un servicio OpenSSH en workstations (rara vez legítimo), el proceso tailscale.exe en máquinas que no deberían correr VPNs, túneles ssh -R apuntando hacia hosts externos, wscript.exe ejecutando .vbs desde carpetas temporales de usuario, y tareas programadas en "highest privileges" que lanzan intérpretes de script. También es relevante monitorear cambios en la configuración de energía con powercfg, porque mantener máquinas despiertas fue parte de su operativa de recolección. Estas son señales de comportamiento más útiles que un hash concreto.

Desde el punto de vista de mitigación inmediata, un primer paso es aislar y preservar evidencia: desconectar de la red las máquinas sospechosas, volcar memoria para análisis forense y recolectar configuraciones de servicios instalados y tareas programadas. Acto seguido, hay que rotar y revocar claves y credenciales potencialmente comprometidas: en el caso de Tailscale, la consola de administración permite eliminar dispositivos y rotar claves para cortar esa malla privada. Más allá de revocar, es crítico buscar artefactos residuales: claves SSH agregadas, archivos de configuración de Tailscale, binarios instalados, y cualquier script o tarea que relance componentes al reinicio.

En una perspectiva de endurecimiento, las organizaciones deberían reducir la capacidad de instalar servicios por usuarios estándar, aplicar políticas de control de aplicaciones (allowlisting) y limitar el uso de clientes remotos a software aprobado con gestión central. La elevación de privilegios vía Start-Process -Verb RunAs expone que la UAC puede ser un vector social: si un usuario acepta elevaciones repetidas, el atacante logra privilegios. Implementar políticas de aprobación de elevaciones, controles de administración remota y la segregación de cuentas (administrador de dominio, administrador local, cuenta de servicio) reduce la superficie de abuso.

No menos importante es la telemetría y la detección basada en comportamiento: las soluciones EDR/EDR-like deben alertar no solo por 'malware conocido', sino por acciones atípicas como la creación de servidores SSH en estaciones de trabajo, la ejecución de procesos firmados desde rutas de usuario, la creación de túneles reversos y el acceso a carpetas de credenciales. Dado que el atacante usó servicios gratuitos (DuckDNS, Backblaze B2, un VPS barato), conviene bloquear y monitorizar dominios dinámicos y buckets públicos como parte de la caza de artefactos externos. La táctica de utilizar proveedores de confianza no debería eximir a un equipo de detección de analizarlos cuando aparecen en contexto sospechoso.

Para pequeñas empresas, la moraleja es doble y dura: por un lado, el daño real no es siempre sofisticado; robar credenciales bancarias y de email exige poca técnica pero produce impacto económico directo. Por otro lado, la respuesta no puede limitarse a un simple "apagar el C2". La contención efectiva exige buscar y eliminar todas las puertas internas que el atacante pudo haberse creado con herramientas legítimas, y después realizar una limpieza completa y una rotación de credenciales con auditoría de accesos y cambios.

Finalmente, el informe de Cato es un recordatorio de que la seguridad efectiva combina prevención, detección y una respuesta que asume que la intrusión puede sobrevivir a cualquier intervención parcial. La caja de herramientas del atacante incluirá siempre herramientas legítimas y servicios cifrados; la diferencia está en una defensa que busca comportamientos anómalos, responde a ellos de forma integral y no confía en que un C2 offline signifique "problema resuelto". Para profundizar en el caso y aprender los indicadores concretos que los investigadores documentaron, el informe completo de Cato está disponible en su blog: https://www.catonetworks.com/blog/, y para entender mejor qué es Tailscale y cómo puede gestionarse de forma segura visite https://tailscale.com/.