Un investigador de malware independiente ha documentado una Backdoor SLEEPWALKER para Windows que no se activa de forma inmediata. Según el análisis publicado, la DLL permanece en estado inerte en memoria hasta que el sistema recibe un paquete de red específicamente construido. En ese momento, la amenaza pasa a ejecutar instrucciones incluidas dentro del propio binario, de manera que el comportamiento queda “disparado” solo bajo condiciones muy concretas.
El hallazgo describe también cómo esta puerta trasera logra pasar desapercibida en entornos de monitoreo, ya que no realiza conexiones de salida propias hacia infraestructura de terceros. Además, el mecanismo de persistencia se apoya en técnicas de carga lateral (side-loading) vinculadas a un ejecutable legítimo.
Qué es Backdoor SLEEPWALKER y cómo se activa
La muestra analizada es una DLL dinámica de 64 bits sin firma con un tamaño de 59.904 bytes. El componente está preparado para cargarse por side-loading dentro del proceso ERAAgent.exe, asociado a ESET Management Agent en Windows.
Antes de cualquier acción, SLEEPWALKER espera. Su activación no depende de tareas periódicas ni de eventos del sistema tradicionales, sino de la llegada de un paquete con un formato que la backdoor reconoce. Una vez que el disparador llega, la carga pasa a ejecutar comandos almacenados como bytecode, es decir, una representación no legible directamente como texto de instrucciones.
Esta arquitectura tiene una consecuencia importante: para comprender qué hace exactamente, el análisis debe recuperar el contenido y los opcodes internos. El investigador señala que el formato de esa “lengua” de instrucciones existe de forma específica dentro del propio archivo, lo que dificulta el uso de claves o firmas genéricas para reconstruir el flujo completo de ejecución.
Imitación de dpapi.dll y señales de archivo en el host
Otro aspecto relevante es la manera en la que la DLL se camufla. SLEEPWALKER imita a dpapi.dll, exportando las mismas siete funciones de protección de datos que ofrece la biblioteca legítima del sistema. También incorpora recursos de versión copiados del ejecutable de administración mencionado, lo que puede confundir revisiones superficiales y análisis apresurados.
En el lado operativo, el análisis indica que no hay dominios, direcciones IP ni URLs incrustados dentro del archivo. Asimismo, la backdoor no establece por sí misma conexiones salientes, de modo que una estación infectada puede parecer “limpia” para herramientas que supervisan comunicación con infraestructuras conocidas.
Como indicador para investigaciones, el informe del investigador incluye elementos que podrían compararse contra un baseline conocido. Entre ellos se encuentran:
- Un archivo inesperado dpapi.dll junto a ERAAgent.exe.
- Un archivo inesperado dpapisvc.dll en el mismo directorio.
- Valores de hash para la muestra: SHA-256 (d347170752a28e2b8c4b8b9f3cab2e3a6541ba11682c94498d26eb9002779d60) y MD5 (2318327b29bb1c0e2d2b5f0211fc7fac).
- La configuración del registro EveryoneIncludesAnonymous establecida en 1.
- Una entrada inesperada en NullSessionPipes.
El propio análisis advierte que los valores de registro solo adquieren significado real al compararse con el estado esperado del sistema. En entornos corporativos, conviene no asumir “maldad” automática si no se tiene un punto de referencia fiable.
Monitoreo de interfaces de red tras el disparador
Una vez se cumple el disparador, la backdoor se comporta como un implante post-compromiso. El análisis describe que su configuración interna cifra datos con AES-256-CCM y que, tras descifrar, genera una instrucción única orientada a vigilar indefinidamente cada interfaz de red para detectar el paquete requerido.
El componente escucha y captura todo el tráfico que atraviesa las interfaces monitoreadas, incluyendo comunicaciones dirigidas a otras máquinas. Esto implica que un sistema afectado podría convertirse, en la práctica, en un punto de observación para segmentos cercanos de red: por ejemplo, un gateway, un servidor VPN o un host que conecte dos subredes podría hacer que el disparo “apunte” a otro equipo, mientras el tráfico relevante circula por el mismo enlace.
Además, el criterio de evaluación se apoya en el nombre del proceso del host, no en su firma ni en su ruta. Esto refuerza la idea de que la backdoor busca operar con las condiciones ya presentes en el sistema comprometido.
Persistencia y carga lateral: sin “parche” contra la aplicación
La persistencia se logra mediante la técnica de side-loading. El análisis indica que la DLL se carga cada vez que inicia el servicio de ESET Management Agent. Pero, según el investigador, el vector no depende de una falla específica en el software de ESET que “deba parchearse”.
En cambio, el mecanismo se apoya en el orden de búsqueda de DLL de Windows. Dicho de otra forma: si la DLL maliciosa se coloca en el directorio esperado, Windows puede cargarla de forma indirecta bajo el flujo normal del proceso.
Para escribir la DLL en el directorio requerido, se requieren privilegios de administrador locales. El propio informe destaca que la backdoor no obtiene esos permisos por sí misma; en lugar de eso, depende del contexto de seguridad del proceso anfitrión en el que se integra.
El resultado es un patrón consistente con un implante diseñado para activarse después del acceso inicial (post-compromise), no como el primer paso de intrusión.
Bytecode, transporte múltiple y disparadores basados en DNS
En el núcleo de SLEEPWALKER, las instrucciones se envían y ejecutan como bytecode, no como comandos legibles en texto. El investigador menciona que la clave y el formato de opcodes existen únicamente dentro de esta muestra, lo que añade opacidad al análisis comparativo.
Se reporta que el lenguaje de 23 instrucciones cubre funciones como planificación, movimiento por etapas de datos, verificación previa de un componente contra un SHA-256 y ejecución directa en memoria.
En cuanto a los canales por los que puede llegar el disparador o la comunicación interna, el informe enumera seis transportes:
- TCP
- UDP
- ICMP
- Canales SMB con pipes con movimiento lateral autenticado
- Captura promiscua (en crudo)
- VMCI de VMware (Virtual Machine Communication Interface)
Un detalle particularmente útil para defensores: el tráfico por VMCI atraviesa la capa de virtualización, por lo que una captura de red entre dos máquinas tradicionales podría no incluir ese tráfico. El informe cita precedentes donde sockets de VMCI se usaron para persistencia entre hosts ESXi comprometidos y sus máquinas invitadas.
Sobre los disparadores, el análisis indica que se implementa un segundo mecanismo basado en DNS dentro del binario. Sin embargo, ese camino no estaría activo en la build examinada. Además, el lenguaje incluye dos instrucciones que observan el trigger: una habilita el listener de paquetes sin procesar, y otra prepara un disparo DNS que no se ejecuta en esta muestra concreta.
Exposición por canal de named pipes y limpieza peligrosa
Para permitir que llamadores no autenticados alcancen su canal de named pipes, SLEEPWALKER ajusta configuraciones en el registro. En específico, establece EveryoneIncludesAnonymous en 1 y añade el nombre de su pipe a NullSessionPipes.
El análisis también señala un punto delicado en la rutina de eliminación (cleanup). En vez de comprobar si la entrada existía antes de la infección, el binario registra si su propia escritura en NullSessionPipes tuvo éxito. Eso puede provocar que una limpieza posterior elimine una entrada legítima que ya estaba presente.
Detección: YARA y escaneo local, con limitaciones
Para ayudar con el reconocimiento, el investigador publicó una regla YARA y un escáner en PowerShell de solo lectura. El objetivo es revisar indicadores como los valores de registro y rastros asociados en una colección de equipos.
El informe afirma que la cobertura de detección para el archivo era baja al publicarse, aunque el investigador no precisa la base exacta de esa evaluación. También advierte que la regla YARA se apoya parcialmente en una clave AES estática y en código de protocolo compilado; por ello, si se recompila con ajustes distintos, una nueva variante podría evadir esa detección.
Por el momento, no se encontró una liberación pública completa de la herramienta de análisis o de la guía de mitigación descrita en el sitio del investigador, al menos en el momento consultado.
Qué significa esto para la respuesta a incidentes
La Backdoor SLEEPWALKER no se trata como un “fallo” de un producto específico que se arregla con un parche puntual. El análisis sugiere que, cuando se confirma coincidencia, la acción más efectiva es una respuesta de incidente y la reconstrucción del entorno afectado.
En la práctica, el enfoque recomendado por el contexto del informe es revisar un baseline confiable (especialmente los valores de registro), buscar artefactos inesperados junto al ejecutable del agente y validar integridad de directorios donde Windows realiza carga de DLL.
Asimismo, si existen sospechas de que un sistema pudo estar dirigido, el investigador indica que las personas interesadas pueden contactarlo directamente para evaluación.
Conclusión
La Backdoor SLEEPWALKER describe una amenaza con enfoque quirúrgico: permanece inactiva hasta recibir un paquete de red construido a medida, ejecuta comandos mediante bytecode y luego se dedica a observar tráfico en interfaces de red. Su diseño evita conexiones salientes, se camufla imitando bibliotecas del sistema y aprovecha la carga lateral ligada al orden de búsqueda de DLL.
Para los equipos de seguridad, la prioridad es la detección por indicadores y la verificación del baseline del host, además de preparar una respuesta que contemple reconstrucción y contención cuando se detecten señales consistentes con esta amenaza.
Fuente: https://thehackernews.com/2026/08/newly-sleepwalker-backdoor-waits-for.html
