- Introducción: La brecha que redefinió la ciberseguridad
- Cómo se llevó a cabo el ataque a SolarWinds
- ¿Por qué la seguridad tradicional no lo detectó?
- Cómo podría haberlo detectado MetaDefender
- Cómo unSandbox Adaptive Sandbox Threat Intelligence detenido el ataque
- Las ventajas de MetaDefender 2.4.0
- Ejemplo práctico: cómo habría quedado el Sandbox
- Lecciones para los defensores: SolarWinds y más allá
- Creación de una defensa preparada para los ataques de día cero
Introducción: La brecha que redefinió la ciberseguridad
A finales de 2020, el ataque a la cadena de suministro de SolarWinds conmocionó a la comunidad de la ciberseguridad.
Al introducir código malicioso en una actualización firmada digitalmente de la plataforma Orion de SolarWinds, los atacantes lograron acceder de forma encubierta a miles de organizaciones de los sectores público y privado. Lo que parecía una actualización de software fiable ocultaba una puerta trasera que permitió llevar a cabo una de las campañas de ciberespionaje más devastadoras de la historia.
Este incidente puso de manifiesto una dolorosa realidad: las defensas basadas en firmas y en la reputación no son suficientes frente a amenazas de día cero sofisticadas y sigilosas. Pero, ¿y si las organizaciones de la cadena de suministro hubieran implementado OPSWAT MetaDefender ?
Con la última versión MetaDefender 2.4.0, OPSWAT un entorno de pruebas adaptativo basado en emulación e integrado con inteligencia sobre amenazas, capaz de detectar de forma única las sutiles anomalías que el malware de SolarWinds intentaba ocultar.
En este blog analizaremos cómo se desarrolló el ataque y, lo que es más importante, cómo MetaDefender podría haberlo detenido.
Cómo se llevó a cabo el ataque a SolarWinds
El ataque a la cadena de suministro de SolarWinds fue posible gracias a la vulneración de un archivo DLL legítimo utilizado en la plataforma de gestión de TI Orion (SolarWinds.Orion.Core.BusinessLayer.dll). Los autores del ataque modificaron este componente de forma sigilosa, incrustando código malicioso directamente en él.
Lo que parecía un cambio menor e inofensivo, con unas pocas líneas discretas en un código fuente conocido, acabó suponiendo una amenaza considerable. Esta DLL formaba parte de una plataforma ampliamente implantada que utilizaban organizaciones tanto del sector público como del privado, lo que hizo que el alcance del ataque fuera sin precedentes.
Oculto en el archivo DLL comprometido se encontraba una puerta trasera totalmente operativa, compuesta por unas 4.000 líneas de código. Este código permitía a los atacantes acceder de forma encubierta a los sistemas afectados, lo que les facilitaba un control persistente sobre las redes de las víctimas sin despertar sospechas.
Uno de los aspectos más críticos de este ataque fue su integración en el propio proceso de compilación del software. El archivo DLL manipulado llevaba una firma digital válida, lo que indicaba que los atacantes se habían infiltrado en la infraestructura de desarrollo o distribución de software de SolarWinds. Esto hizo que el código malicioso pareciera fiable y le permitió ejecutar acciones con privilegios sin activar los controles de seguridad habituales.
Para mantener el sigilo, los atacantes evitaron alterar la funcionalidad original de la DLL. La carga útil inyectada consistía en una modificación mínima: iniciaba un nuevo método en un subproceso independiente, lo que garantizaba que el comportamiento de la aplicación anfitriona permaneciera inalterado. La llamada al método se integró en una función ya existente, RefreshInternal, pero se ejecutó en paralelo para evitar ser detectada.
La lógica de la puerta trasera se encontraba en una clase denominada «OrionImprovementBusinessLayer», un nombre elegido deliberadamente para que se asemejara a los componentes legítimos. Esta clase albergaba la totalidad de la lógica maliciosa, incluidas 13 clases internas y 16 funciones. Todas las cadenas de caracteres estaban ofuscadas, lo que dificultaba considerablemente el análisis estático.
¿Por qué la seguridad tradicional no lo detectó?
- Las firmas digitales no son suficientes: la DLL estaba firmada, por lo que los antivirus y las herramientas de seguridad de los dispositivos la consideraron legítima.
- El análisis estático ha fallado: la ofuscación y las cadenas cifradas ocultaban una lógica sospechosa.
- Las comprobaciones en tiempo de ejecución no lo detectaron: el carácter sigiloso de la puerta trasera hizo que no generara anomalías hasta que se cumplieron unas condiciones muy concretas.
- Punto ciego de la cadena de suministro: los equipos de seguridad solían confiar en las actualizaciones de software sin probarlas primero en un entorno aislado.
No se trataba simplemente de malware; era un ataque a la cadena de suministro diseñado para pasar desapercibido.
Cómo podría haberlo detectado MetaDefender
A diferencia de los entornos aislados basados en máquinas virtuales, que son fáciles de eludir, MetaDefender utiliza emulación a nivel de instrucción y análisis adaptativo de amenazas. Esto le permite detectar comportamientos ocultos incluso cuando los atacantes intentan camuflarlos.
Un entorno de pruebas desempeña un papel fundamental a la hora de detectar este tipo de ataques. Aunque el archivo DLL malicioso cuente con firma digital y haya sido cuidadosamente diseñado para imitar un comportamiento legítimo, un entorno de pruebas puede detectar la puerta trasera insertada mediante el análisis de anomalías a nivel binario.
Las reglas de YARA y las comprobaciones de reputación se han desactivado deliberadamente para este análisis en el entorno de pruebas con el fin de simular las condiciones originales del ataque a SolarWinds, ya que en aquel momento no estaban disponibles.
Informe de DLL limpia:
Filescan.IO - Plataforma de análisis de malware de última generación
Informe sobre DLL troyanizadas:
Filescan.IO - Plataforma de análisis de malware de última generación
A la izquierda vemos el archivo legítimo SolarWinds.Orion.Core.BusinessLayer.dll. A la derecha se encuentra la versión infectada con un troyano responsable del tristemente célebre incidente de SolarWinds.
Repasemos las principales conclusiones que se desprenden del análisis del entorno de pruebas:
- Cifrado de cadenas: el código utiliza una técnica de ofuscación habitual en diversos programas maliciosos: compresión seguida de codificación Base64.
Las consultas WMI suelen asociarse con la identificación del sistema. En este caso, las cadenas correspondientes se cifraron para evitar su detección.
Varios indicadores relacionados con la escalada de privilegios, la suplantación de identidad de usuarios y la manipulación del control de acceso.
Se ha detectado una gran matriz de bytes estática (1096 bytes), que suele utilizarse para incrustar o preparar una carga útil oculta. En este caso, almacena valores enteros que representan hash de nombres de procesos, probablemente con fines de reconocimiento o filtrado. Dado que el entorno de pruebas ha señalado esta anomalía, los analistas podrán investigar el asunto más a fondo.
En resumen, una clase con 4.000 líneas de código puede parecer grande, pero en un proyecto de software de gran envergadura con miles de archivos, es muy fácil pasarla por alto. Ahí es donde el entorno de pruebas resulta indispensable. Pone de relieve los comportamientos extraños e indica a los analistas dónde deben fijarse y qué es lo que realmente importa.
Cómo unSandbox Adaptive Sandbox Threat Intelligence detenido el ataque
1. Análisis de la estructura profunda (DSA)
Antes de la ejecución, Sandbox los archivos binarios para extraer la lógica integrada. En el caso de SolarWinds, habría detectado:
- La gran matriz estática de 1096 bytes que se utiliza para almacenar temporalmente los hash del proceso.
- Cadenas comprimidas y codificadas en base64, típicas del malware.
- La peculiar clase «OrionImprovementBusinessLayer» y sus funciones ofuscadas.
2. Motor antielusión de última generación
MetaDefender 2.4.0 aborda específicamente las tácticas utilizadas en el caso SolarWinds:
- Detectar cargas útiles que solo residen en memoria → Detecta código que nunca se escribe en el disco.
- Desofuscación del flujo de control para .NET → Ideal para descomprimir DLL ofuscadas como Orion.
- Decodificación automática de Base64 → Revela las cadenas cifradas que utilizaron los atacantes.
3. Threat Intelligence
La detección no se limita al entorno de pruebas. MetaDefender se integra con MetaDefender Threat Intelligence, lo que proporciona:
- Más de 50 000 elementos de contenido (direcciones IP, URL, dominios, hash) para el enriquecimiento.
- Búsqueda por similitud para detectar variantes de malware conocido, incluso cuando se ha modificado.
- Puntuación de amenaza para clasificar este archivo DLL como de alta gravedad.
Las ventajas de MetaDefender 2.4.0
La última versión incorpora funciones que abordan directamente amenazas similares a las de SolarWinds:
- Exposición de la carga útil solo en memoria → Habría revelado la ejecución sigilosa en memoria de SolarWinds.
- Descompresión de malware empaquetado → Identifica cargas útiles escalonadas ocultas dentro de matrices estáticas.
- Binarios pseudorreconstruidos → Permite a los analistas obtener una visión completa de las DLL ofuscadas.
- Extracción mejorada de YARA y configuraciones → Extraería las configuraciones del malware a pesar del cifrado.
- Descompresión del cargador .NET → Directamente relacionado con la lógica .NET ofuscada de la DLL de Orion.
Justo cuando empezábamos a redactar este artículo, se hizo pública una nueva campaña dirigida contra la cadena de suministro del ecosistema npm (npm es un gestor de paquetes de JavaScript incluido en Node.js, que permite ejecutar JavaScript fuera del navegador). Esta reciente campaña implicó un gusano autorreplicante llamado «Shai-Hulud», que logró comprometer cientos de paquetes de software. Este incidente se analizó en detalle en la OPSWAT «De Dune a npm: el gusano Shai-Hulud redefine Supply Chain ».
Sin embargo, esta nueva campaña resulta especialmente relevante en el contexto de este artículo, ya que también demuestra que las capacidades de detección MetaDefender están actualizadas y son eficaces contra los ataques a la cadena de suministro. Consulte nuestro informe sobre el archivo malicioso bundle.js, que detecta la descarga de bibliotecas mediante código ofuscado y califica esta actividad como «Probablemente maliciosa».
De acuerdo con las mejores prácticas descritas en la publicación mencionada anteriormente, todas las dependencias de código abierto deben considerarse poco fiables hasta que se haya demostrado su seguridad. Si las actualizaciones de los paquetes npm afectados se hubieran analizado previamente en MetaDefender , se habría identificado cualquier comportamiento malicioso o sospechoso antes de que se propagara.
En conjunto, estas características ponen de manifiesto que MetaDefender está diseñado específicamente para ofrecer el tipo de sigilo y ofuscación en los que se basaron los atacantes de SolarWinds y NPM.
Ejemplo práctico: cómo habría quedado el Sandbox
1. Hallazgos estáticos
a. Nombre de clase confuso y sospechoso (OrionImprovementBusinessLayer).
b. Grandes matrices estáticas vinculadas a valores hash.
c. Cadenas cifradas en Base64.
2. Resultados dinámicos
a. Consultas del sistema WMI.
b. Intentos de escalada de privilegios.
c. Creación de subprocesos ocultos fuera del flujo de trabajo principal de Orion.
3. Threat Intelligence
a. La búsqueda de similitudes muestra una coincidencia superior al 95 % con muestras conocidas de APT.
b. La correlación de los indicadores de amenaza (IOC) permite identificar solapamientos en la infraestructura C2.
c. La puntuación de amenaza clasifica el archivo DLL como «malicioso con alto grado de confianza».
Lecciones para los defensores: SolarWinds y más allá
La filtración de SolarWinds fue una llamada de atención, pero los ataques a la cadena de suministro siguen aumentando. Según el informe «2025 OPSWAT Landscape Report», las infraestructuras críticas siguen siendo uno de los principales objetivos, y los cargadores ofuscados basados en archivos son cada vez más habituales.
MetaDefender ofrece a los defensores:
Resiliencia ante vulnerabilidades de día cero
Detección basada en el comportamiento que no requiere conocimientos previos.
Supply Chain
Cualquier actualización, parche o archivo proporcionado por el proveedor puede ser ejecutado.
Garantía de cumplimiento
Cumple con los requisitos de detección de vulnerabilidades de día cero establecidos por el NIST, NIS2, HIPAA y NERC CIP.
Información útil
IOC de alta fidelidad que se introducen directamente en los flujos de trabajo de SIEM y SOAR.
Creación de una defensa preparada para los ataques de día cero
El ataque a la cadena de suministro de SolarWinds no era imparable, sino que pasó desapercibido. Si se hubiera utilizado MetaDefender , el archivo DLL ofuscado se habría activado, descodificado y marcado mucho antes de que llegara a los entornos de producción.
Hoy en día, a medida que los atacantes perfeccionan sus tácticas de evasión, el sandboxing basado en la emulación ya no es una opción. Es la base de cualquier estrategia seria de defensa contra ataques de día cero.
Con MetaDefender 2.4.0 y OPSWAT Threat Intelligence, las organizaciones pueden pasar de limitarse a reaccionar ante las brechas de seguridad a neutralizarlas de forma proactiva, antes de que se produzcan.
Más información sobre MetaDefender .
Descubre OPSWAT Threat Intelligence
Póngase en contacto con OPSWAT su organización esté preparada para los ataques de día cero.
Descubre OPSWAT Threat Intelligence
Póngase en contacto con OPSWAT su organización esté preparada para los ataques de día cero.
