Fuente de la imagen: https://www.nozominetworks.com/blog/protecting-against-frostygoop-bustleberm-malware (esta web también analiza Frosty Goop).

La especulación de las últimas semanas sobre los ataques a la industria y sobretodo a la infraestructura eléctrica (algo que no es nuevo) hace que revise el trabajo que estoy realizando en el análisis de Frosty Goop. Y durante este análisis me he encontrado con aspectos curiosos. El primero es el uso de Golang. Todo esto lo voy a desarrollar en este artículo.

Esta semana voy a impartir dos charlas técnicas sobre este malware en mi universidad y la semana que viene tendré el privilegio de asistir a la Universidad de Castilla-La Mancha, en el campus de Toledo para exponer estos avances.

La cuestión es: hay que tener en cuenta todo el sistema operacional en España (Europa por extensión) porque es muy vulnerable. Vamos al lío:

Contexto

FrostyGoop es un malware para sistemas de control industrial (ICS) identificado recientemente que apareció en 2024. A principios de ese año, fue utilizado para interrumpir el funcionamiento de una planta de calefacción en Leópolis, Ucrania, dejando sin calefacción a aproximadamente 600 apartamentos durante una ola de frío con temperaturas bajo cero. Este fue el primer caso conocido de malware que abusó directamente del protocolo Modbus/TCP (puerto 502) para enviar órdenes a dispositivos ICS.

A diferencia de los troyanos de acceso remoto (RAT) tradicionales, el “payload” de FrostyGoop consiste en una secuencia de comandos de lectura/escritura en registros Modbus, enviados a controladores lógicos programables (PLC) o unidades de control distribuido. Es probable que haya sido introducido a través de un dispositivo expuesto a Internet (lo más probable es que fueran router MikroTik ocn vulnerabilidades.

Una vez en un host Windows, el binario de FrostyGoop se ejecuta (normalmente mediante un archivo de configuración basado en JSON) para enviar comandos Modbus no autorizados a controladores de calefacción de la marca ENCO. Esto permitió a los atacantes modificar los valores de consigna y las lecturas de sensores, provocando fallos que interrumpieron el suministro de calefacción.

En la práctica, FrostyGoop no era una backdoor ni un worm, sino una herramienta utilizada bajo demanda. Los analistas creen que los operadores la ejecutaban manualmente o mediante scripts, utilizando archivos JSON preconfigurados.

En esencia, el malware lee y escribe secuencialmente registros específicos de PLC, y puede esperar un intervalo determinado entre operaciones. Los binarios de FrostyGoop no presentan cifrado ni empaquetamiento aparente; en cambio, su tamaño (alrededor de 4–6 MB) revela que son ejecutables de Go enlazados estáticamente. Este tamaño elevado es intencionado: muchos motores antivirus tienden a omitir, o a escanear solo parcialmente, archivos inusualmente grandes.

Paradójicamente, esta “hinchazón” beneficia a los atacantes. La mayoría del malware habitual pesa menos de 2 MB, por lo que un archivo mayor a 4 MB resulta llamativo; sin embargo, algunos motores de análisis simplemente lo omiten para conservar recursos.

FrostyGoop, al estar compilado de forma estática en Go, evita dependencias externas (como DLLs o archivos auxiliares de Python) y genera un binario de gran tamaño que puede eludir los análisis rápidos de los antivirus. Reconozco que me ha impactado.

Características

Característica	Detalles
Plataforma	Windows (binario compilado en Go).
Lenguaje	Go (Golang) !!!!
Vector de entrada	Dispositivo ICS expuesto, probablemente un router MikroTik VPNFLIX bug comprometido.
Protocolo usado	Modbus/TCP (puerto 502) para control directo de PLCs.
Comunicación C2	Ninguna tradicional – se ejecuta localmente mediante comandos o archivos JSON.
Configuración	Configurable mediante argumentos de línea de comandos o archivos JSON con listas de tareas.
Registro de actividad	Salida opcional a consola o archivo JSON.
Librerías utilizadas	Librerías Go de código abierto para Modbus, JSON y control de ejecución en cola.
Anti-análisis	Verificación del flag “BeingDebugged” en el PEB de Windows; sin DLLs externas.
Evasión	Binario de gran tamaño (~4–6 MB), lo cual evita algunos escaneos antivirus automáticos.

Modus operandi y payload

El ejecutable de FrostyGoop se ejecuta en un sistema Windows comprometido que tenga conectividad de red con los equipos ICS. Acepta como entrada argumentos por línea de comandos o un archivo de configuración en formato JSON (mira la Tabla 1). El archivo JSON permite definir múltiples “bloques de ataque”, cada uno de los cuales especifica: el registro Modbus objetivo (tipo y dirección), la operación (lectura o escritura) y, de forma opcional, un valor. Un objeto JSON separado, denominado “Cycle”, define los parámetros de temporización (por ejemplo, el retardo entre comandos).

Por ejemplo, la muestra analizada contiene una “TaskList” con operaciones como la lectura de registros de entrada para medir el caudal, o la escritura en registros de control; y un bloque “Cycle” con una función de retardo entre comandos.

Fuente: https://unit42.paloaltonetworks.com/

Una vez lanzado, FrostyGoop abre una conexión TCP al PLC objetivo a través del puerto 502 y ejecuta comandos Modbus de lectura/escritura exactamente según lo especificado. En el incidente de Leópolis, los operadores lo usaron para enviar valores de control falsos a controladores de calefacción de la marca ENCO. Por ejemplo, pudieron haber escrito el valor 0 en las bobinas de “habilitación de bomba”, o alterado los valores de compensación de temperatura, provocando que las bombas se apagaran o que los sensores devolvieran datos erróneos.

Estos comandos Modbus no autorizados causaron fallos operativos —como bombas fuera de servicio o sensores que marcaban “0”—, lo que conllevó una interrupción del servicio de calefacción durante aproximadamente 48 horas, hasta que los comandos fueron detectados y reinicializados.

FrostyGoop ejecuta directamente los comandos, no depende de un canal clásico de command-and-control (C2) ni descarga instrucciones desde un servidor remoto. En su lugar, el atacante precarga las instrucciones (el payload) mediante el archivo JSON y simplemente ejecuta el binario. Esto evita tener que implantar FrostyGoop en cada sistema víctima o mantener una conexión persistente; los atacantes pueden emitir los comandos desde una máquina bajo su control con acceso a la red objetivo, lo que “elimina la necesidad de distribuir (sin ser detectado) el malware en activos dentro de la red atacada”.

Técnicas de evasión y anti-análisis

FrostyGoop presenta un nivel mínimo de ocultación más allá de su gran tamaño binario, que por otro lado le ayuda a pasar los controles. No está empaquetado ni ofuscado de forma compleja: en disco contiene cadenas de texto legibles (algunas provenientes de bibliotecas de código abierto y rutinas de registro de eventos). No obstante, incluye una técnica deliberada de anti-análisis. El malware realiza una comprobación para detectar si está en un entorno de análisis (esto evitaría su detonación ya que sería detectado) de depuración accediendo directamente a la estructura Process Environment Block (PEB) de Windows y leyendo el flag BeingDebugged,

En lugar de invocar la API estándar IsDebuggerPresent(), el código compilado en Go accede a bajo nivel a la estructura PEB y verifica el parámetro BeingDebugged. Si detecta que hay un depurador presente, abortará la ejecución o alterará su comportamiento.

Esto indica que los desarrolladores del malware eran conscientes del uso de herramientas de análisis, e implementaron una verificación de bajo nivel para evitar puntos de interrupción o depuración en entornos virtualizados. Más allá de esto, la única “evasión” de FrostyGoop radica en su modelo de uso: como no establece comunicaciones «beacon» ni se inyecta en otros procesos (usando técnicas clásicas como le process hollowing, etc), las defensas tienen pocos elementos a los que aferrarse. Simplemente realiza lecturas y escrituras de registros a través de Modbus de una forma que, para un sistema OT, puede parecer tráfico de control legítimo —salvo porque los comandos no estaban autorizados.

En resumen, sus mecanismos de evasión se basan en:

Enlace estático: al no depender de bibliotecas dinámicas, evita anomalías de búsqueda de DLLs, aunque esto conlleva un archivo de gran tamaño que algunos motores antivirus omiten escanear.

Verificación PEB: una técnica de anti-depuración sigilosa que puede detectar intentos de análisis dinámico.

Uso de un protocolo ICS común: se camufla dentro del tráfico Modbus/TCP, que muchas redes industriales no supervisan de forma exhaustiva.

Cabe señalar que su estructura de código es legible como binario de Go, por lo que puede ser descompilado o analizado mediante ingeniería inversa (herramientas como Ghidra o IDA Pro ofrecen soporte para ejecutables en Go).De hecho, el uso de bibliotecas Go de código abierto específicas (para Modbus, JSON y gestión de colas) deja huellas características en la tabla de símbolos y en las cadenas del binario.

Impacto en el contexto industrial

El impacto inmediato de FrostyGoop fue una interrupción significativa de infraestructura crítica: unos 600 edificios de apartamentos en Leópolis quedaron sin calefacción central durante aproximadamente 48 horas en condiciones invernales bajo cero. La recuperación requirió que los operadores anularan manualmente los valores alterados en los PLC afectados y restablecieran los parámetros correctos. Es evidentemente un ataque de un Estado-Nación a ciudadanos.

En un sentido más amplio, FrostyGoop demuestra que las redes ICS modernas siguen siendo vulnerables al sabotaje remoto mediante malware. El vector de entrada no fue un correo de phishing ni una memoria USB infectada (como ocurrió en Irán), sino un dispositivo de red vulnerado (un router) que actuó como puente entre los entornos IT y OT. Una vez dentro de la red ICS, había escasa segmentación entre el router comprometido y los controladores de calefacción, lo que permitió al atacante encaminar directamente sus comandos hacia la zona de control.

Desde una perspectiva de ciberseguridad, FrostyGoop resulta alarmante por dos motivos:

(1) Hasta ahora, la mayoría del malware dirigido a sistemas industriales (como Stuxnet, BlackEnergy, Havex, CrashOverride, TRITON, Industroyer/Pipedream, etc.) se enfocaba en redes eléctricas o procesos industriales. Pero FrostyGoop muestra que también es posible manipular controles de calefacción remotos. De hecho, es el primer malware conocido que armó el protocolo Modbus/TCP como vector directo de control. Modbus es omnipresente en la industria (control de plantas, servicios públicos, sistemas de agua, etc.), y en 2024 se estimaba que había más de 46.000 dispositivos Modbus expuestos a Internet.

(2) FrostyGoop pone en evidencia los desafíos de proteger redes OT. Al utilizar tráfico estándar de ICS, el malware esquiva muchas defensas orientadas a IT. Como señalan los investigadores de SANS, enviar comandos Modbus desde fuera de la red “elimina la necesidad de instalar el malware en activos dentro de la red objetivo, evitando así su descubrimiento, análisis y análisis forense”. En la práctica, los atacantes solo necesitan acceso a la subred ICS, sin comprometer cada controlador o estación de trabajo. Este modo de ataque reduce la efectividad de las soluciones de seguridad en los terminales de las salas de control si el adversario ya ha logrado una posición en la red.

En un contexto más amplio, FrostyGoop representa otro punto en la creciente ciberconflictividad contra infraestructuras críticas. Su origen probablemente estatal (todos nos imaginamos el país dada su trayectoria de ataques al sector energético ucraniano) encaja con incidentes anteriores.

El hecho de que FrostyGoop ya esté documentado públicamente implica que cualquier red ICS que utilice Modbus está en riesgo. Las medidas clave de mitigación incluyen:

• Segmentar adecuadamente las redes ICS.
• Corregir vulnerabilidades en routers y cortafuegos expuestos.
• Monitorizar activamente el tráfico Modbus.

Golang (Go) en el desarrollo de malware: tendencias y comparativas

El uso de Go en el malware FrostyGoop no es un caso aislado; de hecho, los investigadores en ciberseguridad han documentado un incremento notable en el malware escrito en lenguajes modernos como Go. Entre mediados de 2021 y principios de 2024, muchos grupos de amenazas (APT) e incluso operadores de ransomware adoptaron Go/Golang como su lenguaje preferido. ¿Por qué? Diversos factores hacen que Go sea atractivo para los autores de malware:

Compilación multiplataforma

Go permite compilar un único código fuente para Windows, Linux, macOS, ARM, etc., sin o con mínimos cambios. Una única base de código puede compilarse para todos los principales sistemas operativos. Esto simplifica el desarrollo: el atacante puede escribir las herramientas una vez y desplegarlas en servidores, estaciones de trabajo, IoT, etc., sin tener que reescribirlas para cada sistema operativo. En cambio, un troyano en C++ debe requerir compilaciones separadas o incluso cambios en el código para cada plataforma. Asimismo, el uso de lenguajes como Python implica incluir intérpretes o usar herramientas como PyInstaller, que dejan artefactos reconocibles tras su desempaquetado. Los binarios en Go contienen todo el runtime y las bibliotecas necesarias dentro del propio ejecutable, sin necesidad de “pegamento” externo ni scripts sueltos.

Binario estático único

Go enlaza de forma estática su biblioteca estándar en el binario. Un simple “hola mundo” en Go puede compilarse en un ejecutable de varios megabytes. Para el malware, esto significa que un único archivo auto-contenido incluye todo lo necesario. A pesar del tamaño, los atacantes aprovechan esta característica ya que omo hemos dicho muchos antivirus evitan escanear archivos muy grandes como optimización de rendimiento.

Facilidad de uso como lenguaje de alto nivel

Go tiene una sintaxis moderna, clara y características integradas (como recolección de basura y primitivas de concurrencia) que aceleran el desarrollo. Los desarrolladores de malware, acostumbrados a C/C++, pueden encontrar en Go un lenguaje más sencillo y menos propenso a errores. Pueden aprovechar directamente bibliotecas del ecosistema Go (clientes HTTP, analizadores JSON, bibliotecas criptográficas, etc.). Go “ofrece muchas ventajas, pero también supone mayor carga para los analistas de malware”, lo que lo convierte en un arma de doble filo. Herramientas como GoBot2 y Veil demuestran que es factible escribir funciones complejas (botnets, generadores de payloads) en Go.

Herramientas y marcos de código abierto

La comunidad Go ha desarrollado numerosos marcos y herramientas, tanto para red teaming como para malware, que los atacantes pueden adaptar fácilmente. Por ejemplo:

• Veil (generador de payloads) incluyó cargas útiles en Go.
• HERCULES es un generador de shellcode en Go.
• GoBot2 es una botnet/C2 en Go con múltiples funciones.

Incluso herramientas de red teaming populares como Sliver (de Bishop Fox) están escritas en Go. Al usar estas herramientas, los atacantes obtienen funciones sofisticadas (canales cifrados, packers, módulos) con mínimo esfuerzo. De hecho, muchos grupos criminales ya prefieren Sliver en lugar del costoso Cobalt Strike, porque “Sliver está escrito en Go, [así que] sus implantes son multiplataforma” y “su personalización tiene una baja barrera de entrada”.

Evasión

Dado que Go aún es relativamente reciente en el ámbito del malware, muchas defensas de red y de endpoint carecen de detecciones especializadas para ejecutables en Go. Las firmas diseñadas para patrones Win32 PE o packers comunes pueden pasar por alto un EXE compilado en Go. Aunque los antivirus principales ya detectan muchas amenazas en Go (incluido FrostyGoop), existe una ventana de oportunidad durante la cual el malware nuevo en Go puede pasar desapercibido. Esto quedó demostrado en un informe de CrowdStrike que mostró un aumento del 80 % en muestras de malware en Go a mediados de 2021. Los atacantes detectaron que familias de amenazas comunes (como los cryptominers) explotaban con suficiente éxito esta brecha.

Ejemplos de malware y herramientas en Go:

Nombre	Tipo/Uso	Características destacadas	Fuentes
FrostyGoop	Sabotaje ICS (energía/calor)	Inyector de payloads Modbus/TCP para PLCs; primer malware en usar Modbus con fines destructivos	Unit42, SANS
GoBot2	Botnet / C2	Botnet en Go con múltiples funciones (HTTP/S, persistencia, carga de archivos)	Unit42
Veil	Generador de payloads	Framework para generar payloads ofuscados; incluye reverse shells en Go	Unit42
HERCULES	Generador de payloads	Creador de reverse shells en Go vía TCP/HTTP/HTTPS; afirma evadir AV	Unit42
CHAOS	Toolkit / RAT	Builder de reverse shells/RATs en Go (TCP, multicast); evade AV por ofuscación por defecto	LMNTRIX
Sliver	Framework Red Team / C2	C2 de código abierto en Go. Implants para Windows, Linux y macOS. Usado como alternativa a Cobalt Strike	Microsoft, Cybereason
Agenda	Ransomware	Ransomware personalizable en Go para sectores como sanidad o educación	TrendMicro
Titan Stealer	Infostealer	Roba credenciales y claves; ejemplo de malware común en Go (eCrime)	CrowdStrike
Grabit / Sebi	RAT/C2	Backdoor modular en Go (y Rust), usado por APT china (Earth Lusca)	Mandiant
Godzilla RAT	RAT / Loader	Downloader en Go activo y vendido en foros; nombre también usado por otros	CheckPoint

Cada uno de estos ejemplos pone de manifiesto por qué se elige Go. Sliver y Veil muestran cómo incluso equipos de red teaming utilizan Go para crear implantes multiplataforma. GoBot2, CHAOS y HERCULES demuestran que es posible escribir botnets y shells completamente funcionales en Go. FrostyGoop y Agenda ilustran que tanto el sabotaje a infraestructuras industriales a nivel estatal como el ransomware moderno también están utilizando Go.

Es importante destacar que muchos de estos proyectos en Go eran de código abierto (en GitHub) antes de ser adoptados por actores criminales, lo que significa que los atacantes pueden inspeccionarlos y reutilizarlos con rapidez. En general, la preferencia por Golang proviene de su combinación de desarrollo rápido y flexibilidad operativa. Las herramientas que se compilan para múltiples plataformas a partir de un único código (“escribe una vez, ejecuta en cualquier parte”) reducen el esfuerzo, especialmente para atacantes que apuntan a sistemas diversos. Los binarios estáticos y auto-contenidos eliminan dependencias del runtime de Python o de Windows, facilitando una entrega más quirúrgica. Sus funcionalidades integradas (como goroutines para concurrencia, channels para coordinación y bibliotecas estándar completas) hacen que los desarrolladores no necesiten integrar muchas librerías de terceros.

Como contrapartida, quienes trabajamos en defensa nos enfretamos a nuevos desafíos: las heurísticas tradicionales (como las anomalías en la importación de DLLs) no son ya muy útiles, y las bases de datos de firmas van muy por detrás frente a las amenazas nuevas escritas en Go.

La creciente lista de malware basado en Go confirma esta tendencia: desde cryptominers hasta RATs, ICS dirigidos y ransomware, los actores de amenazas están aprovechando las ventajas de Go. Por tanto, debemos actualizar los sistemas de detección y análisis en consecuencia: necesitamos dotarnos de herramientas especializadas para desempaquetar e inspeccionar binarios en Go, monitorizar ejecutables grandes sospechosos y además, poder detectar comportamiento anómalo en protocolos de red atípicos (como tráfico Modbus no autorizado).