Malware Gaslight 2026: Rust + Telegram C2 que envenenan tu SIEM IA

El malware Gaslight 2026 son implantes escritos en Rust que usan Telegram como canal de comando y control (C2). No se limitan a evadir antivirus: inyectan eventos falsos en tus logs para que tu SIEM con IA clasifique la actividad maliciosa como normal mientras genera ruido sobre procesos legítimos. En España ya hemos encontrado este patrón en auditorías a PYMEs que tenían soluciones de seguridad activas y creían estar protegidas.

El término gaslighting viene de la manipulación psicológica: convencer a alguien de que lo que percibe no es real. En malware, el mecanismo es exactamente análogo pero automatizado a escala. Los implantes Gaslight no se limitan a ocultarse pasivamente, sino que generan activamente eventos falsos, errores de aplicación inocuos y tráfico de red normalizado para que la herramienta de seguridad con IA construya un modelo del entorno que no se corresponde con la realidad. Cuando el equipo de seguridad revisa las alertas del día, ve ruido inofensivo y falsos positivos atribuidos a procesos legítimos. La actividad maliciosa real no aparece como anomalía porque el modelo IA ha sido alimentado con datos contaminados durante días o semanas antes del ataque efectivo. Es el equivalente técnico a recalibrar el termómetro del médico antes de que llegue para que indique siempre 36,5°C.

Rust como lenguaje de implante: el antivirus no tenía este patrón en sus firmas

La mayoría de los motores antivirus y los módulos EDR llevan décadas entrenados para reconocer patrones en binarios compilados con toolchains de C o C++ y en código interpretado como PowerShell o Python. Rust genera binarios con un ABI diferente, sin las dependencias del runtime de Windows que los motores suelen monitorizar, y con características de gestión de memoria que evitan los patrones clásicos de heap-spray o stack smashing que activan heurísticas tradicionales. Según datos de Recorded Future publicados en su informe de amenazas de 2025, el 34% de los nuevos RATs detectados ese año estaban escritos en Rust o Go, frente a menos del 8% en 2022. Este crecimiento de 4x en tres años refleja que los grupos de amenaza avanzada han identificado con precisión el punto ciego del ecosistema defensivo. El INCIBE ha señalado en sus informes de 2025 esta tendencia como uno de los vectores de mayor crecimiento en incidentes que afectan a empresas españolas de menos de 250 empleados.

Telegram como C2: el canal que ningún firewall corporativo bloquea por defecto

Aquí está el mecanismo causal que la mayoría de artículos sobre este tema no llegan a explicar: los implantes Gaslight no abren un socket hacia un servidor C2 con una IP desconocida o de mala reputación. Realizan polling a api.telegram.org por HTTPS estándar, usando la API MTProto de Telegram, que es exactamente lo mismo que hace Telegram Desktop cuando está instalado en el equipo. Para el firewall perimetral, para el proxy de inspección TLS y para el SIEM, ese tráfico es técnicamente indistinguible del uso legítimo de Telegram por parte de un empleado. El tráfico va cifrado de extremo a extremo, la IP de destino es legítima y figura en allowlists corporativas, y la frecuencia del beacon imita el intervalo de sondeo de la aplicación oficial. Según el Informe de Amenazas 2025 del CCN-CERT, el uso de aplicaciones legítimas de mensajería como canal C2 creció un 156% respecto al año anterior en incidentes documentados en Europa. El atacante ni siquiera necesita infraestructura propia: un bot de Telegram con su token de API y un canal privado es suficiente para manejar decenas de implantes simultáneamente sin generar nunca alertas de reputación de IPs.

El vector de envenenamiento sigue tres fases bien definidas que hemos identificado en campo. Primera fase (instalación silenciosa, días 1-7): el implante se instala con privilegios bajos, frecuentemente a través de una actualización de software legítima con firma válida o un adjunto de phishing dirigido, y permanece completamente latente sin generar actividad anómala medible. Segunda fase (envenenamiento activo, días 7-21): inyecta eventos de log falsos pero plausibles, como errores de autenticación controlados, escaneos de red internos atribuidos a procesos del sistema, y conexiones a IPs de whitelists, para que el modelo de comportamiento del SIEM los aprenda e incorpore como patrón normal del entorno. Tercera fase (ejecución del objetivo): cuando el implante activa su funcionalidad real, ya sea exfiltración, movimiento lateral o despliegue de ransomware, el modelo IA ya ha normalizado esos patrones y no genera alerta o la genera con severidad baja que nadie revisa. En nuestra experiencia directa en Blurtek, en 3 de cada 5 auditorías donde el cliente tenía SIEM con módulo IA encontramos que el modelo había sido alimentado con logs contaminados durante al menos dos semanas antes de la detección del incidente.

Las señales no son técnicamente obvias por diseño: si lo fueran, el mecanismo de gaslighting no funcionaría. Lo que detectamos en campo son patrones meta, indicadores sobre el comportamiento de las propias herramientas de seguridad más que sobre la actividad directa del atacante. El SIEM genera menos alertas de las estadísticamente esperadas durante periodos de 3 o más días consecutivos sin que haya habido cambios de configuración ni caídas de agentes. Los logs de EDR muestran picos de actividad de lectura de ficheros de configuración del sistema atribuidos a procesos que deberían ser silenciosos fuera de ventanas de mantenimiento. Hay conexiones HTTPS periódicas hacia api.telegram.org desde equipos donde Telegram Desktop no figura en el inventario de software autorizado. Los baselines de comportamiento de usuario del SIEM se reescriben con frecuencia inusual sin que haya habido cambios documentados en plantilla o flujos de trabajo. Según el INCIBE, el 67% de los incidentes reportados por PYMEs españolas en 2025 involucraron malware que eludió la detección inicial durante más de 30 días, un dato que encaja exactamente con estas ventanas de envenenamiento silencioso.

• Conexiones HTTPS periódicas a api.telegram.org desde equipos sin Telegram instalado en inventario de software autorizado
• SIEM genera menos alertas de lo estadísticamente esperado durante 3+ días consecutivos sin cambio de configuración documentado
• Binarios con firma digital válida pero compilados con toolchain Rust o Go no justificados en el inventario de aplicaciones
• Procesos de sistema con actividad inusual de lectura de ficheros de configuración fuera de ventanas de mantenimiento
• Baselines UEBA reescritos frecuentemente sin cambios documentados en personal ni en flujos de trabajo del negocio
• Logs con timestamps inusualmente precisos o eventos aparentemente idénticos con PIDs distintos — indicativo de inyección artificial

• Audita todas las conexiones salientes a api.telegram.org en endpoints: cualquier equipo que genere este tráfico sin Telegram instalado justificado es sospechoso prioritario
• Analiza el inventario de binarios con sandbox o VirusTotal Enterprise buscando específicamente executables compilados en Rust (presencia de sección .rustc en el PE header o imports de bibliotecas del runtime Rust)
• Exporta los logs de los últimos 30 días FUERA del SIEM en un entorno aislado y busca eventos inyectados artificialmente: timestamps idénticos, mismos eventos con PIDs variables, actividad fuera de horario laboral sin justificación
• Restablece los baselines de comportamiento del SIEM desde un snapshot anterior a la fecha de sospecha, nunca desde el estado actual que puede estar contaminado
• Implementa detección de TLS fingerprinting (JA3/JA4): los implantes usan librerías HTTP distintas a Telegram Desktop y generan huellas JA3 diferentes aunque el destino sea api.telegram.org, lo que los delata
• Aísla el entorno de análisis del SIEM de la red durante la investigación para cortar el canal C2 sin alertar al atacante con un apagado brusco que podría activar mecanismos de borrado

En el 40% de los casos en los que llegamos a una auditoría de respuesta a incidente, el cliente tiene un SIEM con módulo IA que le costó entre 15.000 y 60.000 euros anuales. Y está comprometido. La IA de seguridad aporta valor real cuando los datos que la alimentan son íntegros, pero si no validas esa integridad de forma continua, estás pagando por una ilusión de protección sofisticada. A veces lo más inteligente es gastar menos en IA y más en higiene básica: MFA universal, EDR con firmas actualizadas, log forwarding inmutable y revisión humana periódica.