# SysGoRAT, el espía que escribe sus scripts con IA y vive en Linux > Unit 42 documenta CL-UNK-1211, una campaña de espionaje contra servidores Linux de gobiernos que usa scripts generados por IA y borra sus registros. > Por José Maldonado · Ciberseguridad · 2026-11-03 Servidores Linux de entidades gubernamentales y de infraestructuras vinculadas al Estado han sido el objetivo de una campaña de espionaje que se extendió al menos de octubre de 2025 a abril de 2026. Palo Alto Networks Unit 42 la sigue bajo el nombre [CL-](https://thehackernews.com/2026/11/government-linux-servers-targeted-with.html)U[NK-1211](https://thehackernews.com/2026/11/government-linux-servers-targeted-with.html), donde la primera parte indica que es un grupo sin nombre conocido y la segunda que su motivación no está clara. Lo llamativo no es el objetivo, es cómo escribía el atacante. Los scripts que usó para mantenerse dentro llevaban [notas de razonamiento](https://unit42.paloaltonetworks.com/ai-campaign-targets-linux-infrastructure/) paso a paso, del tipo que produce un asistente conversacional cuando explica su propio código. No eran comentarios de documentación para otros programadores, eran explicaciones dirigidas a quien había dado la instrucción inicial. Ese detalle, más que cualquier indicador técnico, apunta a que una parte del trabajo la hizo un modelo de lenguaje. La campaña combina lo viejo y lo nuevo sin disimulo. Por un lado, hay herramientas de código abierto, backdoors multiplataforma y [webshells](https://observatorioblockchain.com/ciberseguridad/) en PHP; por otro, una capa de generación automática que acelera la producción de scripts y reduce el esfuerzo manual. El resultado es un ataque de espionaje clásico con una cadencia de desarrollo que no encaja con la de un equipo humano pequeño. ## Un playbook que se disfraza de auditoría El grupo siguió un guion bastante completo. Hizo reconocimiento extenso, mantuvo acceso persistente y se dedicó a volcar bases de datos sensibles. También intentó exfiltrar buzones de correo institucionales, un paso que suele tener un objetivo indirecto: con el correo se abren las cuentas de redes sociales asociadas y se llega a contactos que no están en el servidor comprometido. Uno de los detalles más fríos es el camuflaje. Los atacantes plantaron marcadores que imitan los que deja un equipo de red team durante una prueba de seguridad legítima. La idea es sencilla: si alguien encuentra esas huellas, la primera hipótesis será que hay una auditoría en marcha y no una intrusión. Comprar tiempo dentro de una red es a veces más valioso que cualquier herramienta. También intentaron desactivar protecciones de endpoint y borrar registros del sistema. Son dos acciones que, juntas, describen a un adversario que sabe que la detección llega por los logs y que prefiere eliminar la evidencia antes que esconderla. La combinación de ambas técnicas complica mucho la reconstrucción posterior del incidente. ## Cuando el código delata a su autor El hallazgo más interesante del análisis es lingüístico. Varios scripts incluían notas conversacionales que explicaban la lógica del código, algo que no aparece en la documentación técnica habitual. Un programador experimentado comenta el porqué de una decisión, no describe paso a paso lo que va a hacer a continuación como si hablara con alguien. Ese patrón es consistente con código copiado de la salida de un modelo o generado por un agente automático que razona en voz alta. No prueba por sí solo que el atacante usara IA, pero suma: la estructura es coherente, el estilo es explicativo y las notas no aportan nada a quien ya entiende el script. La implicación práctica es que las herramientas de atribución basadas en estilo de programación pierden fiabilidad. Si varios grupos usan los mismos modelos para escribir sus utilidades, el código se parece entre sí aunque los autores sean distintos. La huella útil deja de estar en cómo se escribe y pasa a estar en qué se hace y contra quién. La campaña recuerda algo que el sector repite poco. Los servidores Linux no son inmunes, simplemente han tenido menos malware dirigido porque el escritorio lo ocupaban otros sistemas. Cuando el objetivo es una infraestructura gubernamental, el sistema operativo del servidor es lo de menos: importa que haya servicios expuestos, credenciales débiles y paneles de administración al alcance. El [CVE-2026-98432 del kernel](https://observatorioblockchain.com/ciberseguridad/cve-2026-98432-kernel-tcp-ubuntu-rhel-sin-parche/), que afectó a Ubuntu y RHEL con una puntuación de 9.8, mostró el mismo mes que el ecosistema Linux también acumula fallos críticos y que las distribuciones tardan lo suyo en cubrirlos. La diferencia es que en Linux la explotación remota del kernel es excepcional, mientras que una webshell en un PHP mal configurado sigue siendo el pan de cada día. Las webshells son la parte menos glamurosa y la más eficaz. Un fichero de pocas líneas en un directorio con permisos generosos da acceso persistente sin exploits y sin binarios sospechosos. Frente a eso, la monitorización de integridad de ficheros y la revisión de lo que se sube a producción valen más que cualquier antivirus. ## Lo que delata a un script escrito por un modelo Un analista que revisa código malicioso busca patrones de autor. Durante años, esos patrones venían de la escuela de cada grupo: nombres de variables, formas de ofuscar, manías al formatear. Los scripts de esta campaña rompen esa lógica porque no escriben para un lector humano, escriben para justificar una decisión ante quien dio la orden. Ese estilo conversacional deja marcas útiles. Comentarios que describen lo que el código va a hacer antes de hacerlo, explicaciones redundantes de funciones obvias y una estructura que imita un tutorial. En un fichero de persistencia para un servidor comprometido, ese tono es tan fuera de lugar como una firma al pie de un exploit. La detección no puede depender solo de leer scripts, porque el script cambia con cada oleada. Conviene cruzar señales: procesos que no corresponden al horario, tareas programadas nuevas, ficheros PHP con fecha reciente en directorios estáticos y conexiones salientes hacia dominios registrados hace semanas. Cada una por separado se explica, juntas cuentan una historia. ## Qué mirar en tu propia infraestructura La primera revisión es de inventario. Qué servidores Linux hay, quién administra cada uno, qué servicios escuchan en la interfaz pública y qué cuentas tienen acceso. La segunda es de comportamiento: procesos que aparecen fuera de horario, conexiones salientes a dominios jóvenes, tareas programadas que nadie recuerda haber creado y ficheros PHP con fecha reciente en directorios que deberían estar congelados. Conviene además revisar los buzones corporativos como superficie de riesgo y no solo como herramienta de trabajo. Si el acceso al correo permite recuperar cuentas en redes sociales, el buzón es una llave maestra. La autenticación multifactor con claves físicas y la separación entre cuentas personales y profesionales reducen ese camino. Finalmente, el registro no sirve de nada si el atacante puede borrarlo. Enviar los logs a un sistema externo con permisos de solo escritura es una medida barata y aburrida que arruina la estrategia descrita en este caso. Sin ella, la investigación posterior se queda en conjeturas sobre lo que pudo pasar. ## La autoría se vuelve difusa CL-UNK-1211 tiene nombre porque nadie sabe quién está detrás, ni siquiera con qué intención exacta. Esa ambigüedad va a ser cada vez más común. Cuando el código lo escribe un modelo a partir de instrucciones, el estilo delata al modelo y no al grupo, y las herramientas que durante años sirvieron para atribuir campañas pierden buena parte de su valor. Para las organizaciones atacadas, la pregunta sobre el autor es secundaria. Lo que decide el daño es cuánto tiempo estuvo el intruso dentro y qué se llevó. En una campaña de siete meses contra infraestructura gubernamental, ese tiempo se mide en decisiones que ya no se pueden revertir.