BrickStorm: cuando el acceso persistente se convierte en infraestructura

BrickStorm no representa una ruptura técnica radical. No introduce exploits desconocidos ni mecanismos crípticos diseñados para impresionar a analistas. Su relevancia es mucho más incómoda: demuestra que el espionaje estatal moderno ha dejado de comportarse como un ataque y ha comenzado a operar como infraestructura silenciosa. No entra para destruir, ni siquiera para controlar. Entra para quedarse.

Esta campaña encarna un cambio profundo en la forma en que los actores patrocinados por Estados conciben la intrusión. BrickStorm no compite por velocidad ni por volumen. Compite por permanencia. Su diseño responde a una lógica de largo plazo, donde cada decisión técnica busca minimizar fricción, ruido y probabilidad de detección. El malware no se impone al entorno; se adapta a él. Se instala donde los controles son más laxos, utiliza protocolos comunes y se comunica a través de infraestructuras que nadie quiere bloquear.

El resultado es una operación que no dispara alarmas evidentes y que, en muchos casos, solo se vuelve visible cuando el daño ya no es técnico, sino estratégico.

Del acceso inicial al asentamiento operativo

Uno de los errores más comunes al analizar campañas como BrickStorm es obsesionarse con el vector inicial. En realidad, el acceso inicial es apenas una condición necesaria, no el evento central. BrickStorm aparece cuando la intrusión ya ocurrió, cuando el atacante ya tiene un punto de apoyo confiable y cuando la organización cree haber superado el peor momento.

Aquí emerge el concepto clave de asentamiento operativo: la fase donde el atacante deja de explorar y comienza a habitar. BrickStorm está diseñado exactamente para ese momento. Se despliega cuando el entorno ya es relativamente conocido, cuando existen credenciales válidas y cuando el riesgo de ser expulsado es bajo. No busca ampliar superficie de ataque de forma agresiva, sino consolidar acceso y observar.

Este enfoque explica por qué muchas organizaciones no detectan la intrusión. Sus controles están orientados a eventos disruptivos, no a comportamientos discretos y sostenidos en el tiempo.

Un implante diseñado para parecer normal

Desde el punto de vista técnico, BrickStorm destaca por su sobriedad. El código es funcional, estable y mantenible. No hay capas excesivas de ofuscación ni técnicas exóticas que puedan llamar la atención. El malware actúa como un backdoor persistente con capacidades de ejecución remota, gestión de archivos y recolección de información del sistema.

Su comunicación con infraestructura de mando y control utiliza protocolos estándar, intervalos regulares y patrones de tráfico que imitan aplicaciones legítimas. No hay picos de actividad ni consumo anómalo de recursos. BrickStorm se comporta como un servicio más.

Esta normalidad es intencional. Cuanto más se parece al software legítimo, más difícil resulta distinguirlo del ruido cotidiano. La campaña demuestra que el malware moderno no necesita parecer malware. Necesita parecer rutina.

El camuflaje perfecto: infraestructura legítima

Uno de los elementos más sofisticados de BrickStorm es su uso sistemático de infraestructura legítima para resolver nombres y mantener comunicación persistente. En lugar de servidores oscuros o dominios efímeros claramente maliciosos, el implante utiliza servicios ampliamente adoptados en Internet moderno.

Esto introduce un dilema operativo para los defensores. Bloquear este tráfico implica afectar servicios críticos del negocio. Permitirlo sin control abre una vía de comunicación casi invisible. BrickStorm explota esa tensión con precisión quirúrgica.

Aquí se evidencia una debilidad estructural en muchas arquitecturas de seguridad: se asume que lo legítimo es benigno. BrickStorm demuestra que, en el contexto adecuado, lo legítimo puede ser el mejor disfraz.

vCenter: cuando el plano de control se vuelve vector

La campaña expone con claridad el riesgo sistémico de comprometer plataformas que operan como planos de control. En entornos virtualizados, vCenter no es un servidor más: es el cerebro que orquesta infraestructura, identidades y flujos críticos.

BrickStorm aprovecha esta centralidad. Una vez con acceso privilegiado, se instala en rutas del sistema y modifica mecanismos de arranque para asegurar persistencia tras reinicios. El implante se copia a ubicaciones que imitan componentes legítimos de la plataforma, utilizando nombres plausibles y rutas esperadas.

Este tipo de persistencia no busca ocultarse mediante complejidad técnica, sino mediante verosimilitud operativa. El malware parece pertenecer al sistema que infecta.

El impacto potencial es enorme. Desde vCenter, el atacante puede observar, preparar y eventualmente pivotar hacia sistemas de identidad, llaves criptográficas y cargas de trabajo críticas, todo sin generar tráfico ostensiblemente anómalo.

Windows también importa

BrickStorm no se limita a appliances o sistemas Linux. Existen variantes diseñadas para operar en entornos Windows, con capacidades equivalentes de persistencia, ejecución remota y gestión de archivos. En estos casos, el implante se integra al sistema mediante mecanismos nativos como tareas programadas, manteniendo acceso sin requerir exploits adicionales.

Esta dualidad es estratégica. El appliance comprometido ofrece el punto de apoyo inicial y la persistencia silenciosa; los endpoints Windows ofrecen acceso a credenciales, correo, datos operativos y Active Directory. Juntos forman una cadena de valor para el espionaje prolongado.

Para los defensores, esto implica que la respuesta no puede ser parcial. Limpiar un appliance sin revisar endpoints deja viva la operación. Limpiar endpoints sin cerrar el plano de control deja la puerta abierta.

Ivanti y la falacia del “ya parchamos”

BrickStorm también expone una falacia peligrosa: la idea de que parchear equivale a erradicar al atacante. En varios escenarios, el acceso inicial se originó en appliances de acceso remoto vulnerables. El parche se aplicó, pero el atacante ya había sembrado persistencia.

El momento posterior al parche es, paradójicamente, uno de los más favorables para el adversario. La organización relaja la vigilancia, asume que el riesgo fue mitigado y continúa operando. BrickStorm se despliega exactamente ahí, cuando la atención baja y el entorno sigue comprometido.

La lección es clara: parchear cierra la puerta, pero no revisa quién entró antes. Sin rotación de credenciales, verificación de integridad y hunting activo, el parche solo estabiliza un entorno ya infiltrado.

Movimiento lateral sin ruido

BrickStorm no se mueve de forma agresiva. No escanea redes completas ni lanza ataques de fuerza bruta. Utiliza credenciales válidas, relaciones de confianza existentes y conocimiento previo del entorno. Se desplaza solo cuando la probabilidad de éxito es alta.

Desde fuera, este comportamiento se confunde fácilmente con actividad administrativa legítima. Desde dentro, solo una combinación de visibilidad profunda y criterio analítico permite distinguirlo del día a día operativo.

Aquí se revela otra debilidad común: muchos SOCs están optimizados para volumen y velocidad, no para detectar sutilezas. BrickStorm no genera alertas espectaculares. Genera pequeñas inconsistencias que solo cobran sentido cuando se correlacionan.

El verdadero objetivo: inteligencia, no control

A diferencia de campañas orientadas a extorsión o sabotaje, BrickStorm tiene un objetivo claro y clásico: información estratégica. Documentos internos, configuraciones, diagramas, flujos de decisión, credenciales. Todo aquello que permite comprender cómo funciona una organización desde dentro.

Este tipo de información no se monetiza de inmediato. Se acumula, se cruza con otras fuentes y se utiliza cuando resulta estratégicamente conveniente. El daño no siempre es visible en el corto plazo, lo que lleva a subestimarlo.

Pero cuando las consecuencias aparecen, ya es demasiado tarde para atribuirlas a una intrusión silenciosa que ocurrió meses atrás.

Por qué los controles tradicionales no bastan

BrickStorm no evade los controles; los desborda conceptualmente. Firewalls, EDR y SIEM siguen funcionando, pero observan eventos, no contextos. Detectan anomalías claras, no normalidades maliciosas.

La detección efectiva requiere algo más complejo: conocimiento profundo del entorno, líneas base dinámicas y analistas capaces de cuestionar lo que parece normal. Requiere asumir que el atacante puede estar dentro hoy, operando con calma.

Ese nivel de madurez no se logra con una compra puntual. Es una disciplina operativa.

Una advertencia estratégica

BrickStorm no es una anomalía. Es un anticipo. Representa una forma de operar que probablemente se vuelva común en campañas de espionaje avanzado: persistente, discreta, apoyada en infraestructura legítima y enfocada en el largo plazo.

Ignorar este patrón no es una opción viable. El perímetro ya no es el campo de batalla principal. El verdadero desafío está en detectar al adversario cuando ya se comporta como parte del sistema.

Porque en el espionaje moderno, ganar no es entrar rápido. Es no ser visto.

IOCs, correlaciones y medidas preventivas

En sistemas Linux, appliances y entornos VMware, la persistencia y el masquerading de BrickStorm dejan rastro en rutas como /etc/sysconfig/, /etc/sysconfig/network/, /etc/sysconfig/init, /opt/vmware/sbin/vmware-sphere, /usr/java/jre-vmware/bin/updatemgr, /home/vsphere-ui/, /home/bin/netmon, /home/bin/logd, /home/runtime/logd y /home/config/logd.spec.cfg. Para hunting, los endpoints funcionales observados en el implante incluyen /api/file/change-dir, /api/file/delete-dir, /api/file/delete-file, /api/file/mkdir, /api/file/list-dir, /api/file/rename, /api/file/put-file, /api/file/get-file, /api/file/slice-up y /api/file/file-md5.

A nivel de red, la campaña se apoya en resolución DNS sobre HTTPS (DoH) desde sistemas que no deberían usarlo, resolviendo contra resolvers públicos como 1.1.1.1, 1.0.0.1, 8.8.8.8, 8.8.4.4, 9.9.9.9, 9.9.9.11, 149.112.112.112 y contra IPs 45.90.28.160 y 45.90.30.160. Entre los dominios y hosts asociados a C2 y post-explotación aparecen opra1.oprawh.workers.dev, ms-azure.azdatastore.workers.dev, ms-azure.herokuapp.com, oast.fun, cpanel.netbar.org, pan.xj.hk y akapush.us.to. Entre las IPs observadas en campañas relacionadas figuran 8.218.240.85, 98.142.138.21, 103.13.28.40, 103.27.110.83, 103.73.66.37, 193.149.129.191 y 206.188.196.199.

En Windows, se han observado los binarios CreatedUACExplorer.exe y CreateUACExplorer.exe (con hashes SHA256 propios de cada muestra), desplegados con persistencia vía tareas programadas y ejecutados con nombres que imitan componentes del sistema.

Como correlaciones operativas clave destacan: cambios en archivos de arranque o init en appliances seguidos de tráfico DoH saliente; ejecución de binarios desde rutas de sistema no habituales con nombres plausibles; sesiones WSS persistentes desde infraestructuras de administración; y actividad administrativa válida desde orígenes atípicos tras el compromiso de una VPN o un appliance.

A nivel de infraestructura, las medidas preventivas pasan por tratar el DoH como servicio administrado y no como tráfico web genérico, restringir el egress de appliances de administración a resolvers internos, aplicar monitoreo de integridad de archivos en rutas críticas de sistemas de control, segmentar estrictamente los planos de control con MFA obligatorio, y asumir compromiso previo tras cualquier vulnerabilidad explotada en un appliance, ejecutando limpieza profunda en vez de solo parchear. A nivel de endpoint, conviene aplicar control estricto de ejecución y detección de tareas programadas anómalas, hunting retroactivo por hashes y nombres plausibles, rotación masiva de credenciales tras un compromiso de infraestructura, y revisión de identidad y servicios de autenticación tras cualquier incidente en VPN o vCenter.