Necurs y Rustock: Rootkits de Kernel al Servicio de Botnets de Spam

La simbiosis entre rootkits y botnets de spam

Entre 2006 y 2020, dos familias de malware dominaron el envío masivo de spam a nivel global: Rustock y Necurs. Ambas compartían una filosofía arquitectónica: usar drivers de kernel de Windows para proteger los componentes de la botnet que operaban en user-mode. El rootkit no era el payload final, sino el escudo que garantizaba la persistencia del bot de spam.

Esta estrategia es lógica desde la perspectiva del atacante. Un bot de spam necesita ejecutarse durante meses en cada máquina infectada para ser rentable. Sin protección a nivel de kernel, el antivirus detecta el proceso de envío masivo de correo en cuestión de horas. Con un rootkit de kernel, el bot se vuelve invisible para las herramientas de seguridad estándar.

Rustock (2006-2011): el rey del spam

Contexto operativo

Rustock fue la botnet de spam más prolífica de su era. En su pico de actividad (2008-2010), se estimaba que controlaba entre 1 y 2 millones de máquinas infectadas y generaba entre 30 y 40 mil millones de emails de spam por día. Para dimensionar la cifra: representaba aproximadamente el 40% de todo el spam global.

El contenido del spam era variado: farmacéuticas falsas (Canadian Pharmacy fue la marca más recurrente), software pirata, réplicas de relojes y esquemas financieros. La monetización se realizaba via programas de afiliados que pagaban por volumen de envío.

Driver polimórfico

El componente central de Rustock era un driver de kernel (.sys) que implementaba polimorfismo en cada reinicio del sistema. A diferencia de malware polimórfico convencional que varía en disco, Rustock mutaba su driver durante la fase de carga:

Secuencia de carga de Rustock:
1. Boot → Windows carga el driver desde disco
2. Driver descomprime su payload real en memoria (cifrado RC4)
3. El payload en memoria difiere del contenido en disco
4. En el siguiente reinicio, el driver se reescribe con variaciones
5. Checksums y firmas estáticas no coinciden entre reinicios

Esta técnica era efectiva contra los antivirus de la época, que dependían fuertemente de firmas estáticas. Cada instancia de Rustock tenía un driver diferente en disco, y ese driver cambiaba con cada reinicio.

Ocultación via DKOM + IRP hooking

Rustock combinaba dos técnicas de kernel para lograr invisibilidad completa:

DKOM (Direct Kernel Object Manipulation): Desenlazaba su DRIVER_OBJECT de la lista PsLoadedModuleList del kernel. Esto ocultaba el driver de herramientas como DriverQuery, el Device Manager, y las APIs estándar de enumeración de drivers (NtQuerySystemInformation).

IRP hooking: Interceptaba los IRP (I/O Request Packets) en los drivers del sistema de archivos (NTFS). Cuando cualquier proceso intentaba listar el directorio donde residía el driver de Rustock, el hook filtraba la entrada correspondiente de los resultados. El archivo existía en disco pero era invisible para el Explorer, el CMD y las herramientas antivirus.

Flujo de ocultación de archivos via IRP hooking:

Aplicación → CreateFile("C:\Windows\System32\drivers\")
    │
    ▼
NTFS.sys IRP_MJ_DIRECTORY_CONTROL (hookeado por Rustock)
    │
    ▼
Rustock filter: ¿el nombre coincide con mi driver?
    │
    ├── SÍ → eliminar entrada del buffer de resultados
    │
    └── NO → pasar al handler original sin modificar

Comunicación C&C

Rustock usaba una lista hardcodeada de IPs para sus servidores de comando y control, con HTTP como protocolo de transporte. Los comandos incluían:

• Listas de destinatarios de spam (descargadas en lotes)
• Templates de emails con variables de personalización
• Actualizaciones del propio bot
• Cambios de servidores C&C de respaldo

La ausencia de DGA (Domain Generation Algorithm) fue la debilidad que permitió su desmantelamiento.

Operación b107: desmantelamiento (marzo 2011)

Microsoft lideró la Operación b107 con soporte legal y técnico:

1. Análisis forense: Microsoft MMPC (Malware Protection Center) analizó muestras de Rustock durante meses para identificar todos los servidores C&C
2. Orden judicial: Obtenida en el Distrito Oeste de Washington bajo la ley federal de fraude informático
3. Incautación simultánea: El 16 de marzo de 2011, marshals federales incautaron servidores en cinco proveedores de hosting en siete ciudades de EE.UU.
4. Resultado: Los bots perdieron contacto con los C&C. Sin mecanismo de recuperación (no había DGA ni P2P), la botnet colapsó en días

El volumen global de spam cayó un 30-40% en las semanas posteriores a la incautación.

Necurs (2012-2020): evolución del concepto

Arquitectura modular

Necurs apareció en 2012 con una arquitectura más sofisticada que Rustock. En lugar de un driver monolítico, Necurs separaba sus componentes:

Arquitectura Necurs:

┌─────────────────────────────────────────────┐
│                  KERNEL MODE                 │
│                                              │
│  ┌──────────────────────────────────────┐   │
│  │ Minifilter Driver (.sys)             │   │
│  │ - Protege archivos del bot           │   │
│  │ - Protege claves de registro         │   │
│  │ - Bloquea terminación del proceso    │   │
│  └──────────────────────────────────────┘   │
├─────────────────────────────────────────────┤
│                  USER MODE                   │
│                                              │
│  ┌──────────────┐  ┌────────────────────┐   │
│  │ Bot principal │  │ Módulos de payload │   │
│  │ - C&C comm   │  │ - Spam engine      │   │
│  │ - DGA        │  │ - Proxy module     │   │
│  │ - Updates    │  │ - DDoS module      │   │
│  └──────────────┘  └────────────────────┘   │
└─────────────────────────────────────────────┘

El driver de kernel no enviaba spam. Su función era exclusivamente defensiva: proteger los componentes de user-mode contra la detección y eliminación.

Minifilter driver: protección legítima para fines maliciosos

A diferencia de Rustock (que hookeaba IRPs directamente), Necurs usaba la API oficial de minifilter de Windows (FltRegisterFilter). Los minifilters son el mecanismo legítimo que usan los antivirus, los sistemas de backup y las soluciones DLP para monitorizar operaciones de I/O.

// Registro simplificado del minifilter de Necurs
const FLT_REGISTRATION FilterRegistration = {
    sizeof(FLT_REGISTRATION),
    FLT_REGISTRATION_VERSION,
    0,                              // Flags
    NULL,                           // Context registration
    Callbacks,                      // Operation callbacks
    NecursFilterUnload,             // Unload routine
    NecursInstanceSetup,            // Instance setup
    // ...
};

// Callbacks registrados por Necurs
const FLT_OPERATION_REGISTRATION Callbacks[] = {
    { IRP_MJ_CREATE,        0, NecursPreCreate,  NULL },
    { IRP_MJ_SET_INFORMATION, 0, NecursPreSetInfo, NULL },
    { IRP_MJ_WRITE,         0, NecursPreWrite,   NULL },
    { IRP_MJ_CLEANUP,       0, NecursPreCleanup, NULL },
    { IRP_MJ_OPERATION_END }
};

El callback NecursPreCreate verificaba si el archivo que se intentaba abrir pertenecía al bot. Si era así, devolvía STATUS_ACCESS_DENIED. Lo mismo aplicaba para operaciones de escritura (IRP_MJ_WRITE) y eliminación (IRP_MJ_SET_INFORMATION con FileDispositionInformation).

Este enfoque era más estable que el IRP hooking directo de Rustock: usaba APIs documentadas de Microsoft, sobrevivía a actualizaciones del kernel, y era menos detectable por herramientas anti-rootkit que buscaban hooks en la dispatch table de drivers.

DGA: resiliencia contra takedowns

Necurs aprendió de la caída de Rustock. En lugar de IPs hardcodeadas, implementaba un Domain Generation Algorithm (DGA) que generaba miles de dominios pseudoaleatorios:

Pseudocódigo del DGA de Necurs:

function generate_domains(seed, date):
    domains = []
    for i in range(2048):
        hash = custom_hash(seed + date.year + date.month + date.day + i)
        length = (hash % 12) + 8        // dominios de 8-19 caracteres
        tld = select_tld(hash)           // .com, .net, .org, .biz, .info
        domain = ""
        for j in range(length):
            domain += chr((hash >> (j * 5)) % 26 + ord('a'))
        domains.append(domain + "." + tld)
    return domains

Cada día, el bot generaba una lista de dominios candidatos y los probaba secuencialmente. El operador solo necesitaba registrar uno de esos dominios para restablecer el control. Esto hacía que el bloqueo por listas negras fuera impracticable: bloquear 2.048 dominios nuevos cada día es inviable para la mayoría de organizaciones.

Escala y payloads distribuidos

En su pico (2016-2017), Necurs controlaba aproximadamente 6 millones de bots. Más allá del spam, la botnet se convirtió en una plataforma de distribución para otros malware:

Payload	Periodo	Función
Locky	2016-2017	Ransomware distribuido via spam con macros maliciosas
Dridex	2015-2019	Troyano bancario, documentos Word con macros
TrickBot	2017-2018	Sucesor de Dyre, modular banking trojan
Scarab	2017	Ransomware, campañas puntuales de alto volumen
FlawedAmmyy	2018	RAT basado en código fuente filtrado de Ammyy Admin

La relación con Locky fue particularmente significativa. Durante 2016, Necurs era el principal vector de distribución de Locky, enviando millones de emails diarios con adjuntos .docm o .js que descargaban el ransomware. Cuando Necurs dejaba de enviar spam temporalmente (por mantenimiento o actualizaciones), las detecciones globales de Locky caían de forma proporcional.

Desmantelamiento de Necurs (marzo 2020)

Microsoft coordinó una operación con 35 países para desmantelar Necurs:

1. Cracking del DGA: Investigadores de Microsoft, BitSight y otros analizaron el algoritmo DGA de Necurs y lograron predecir con precisión los dominios que generaría en los siguientes 25 meses
2. Registro preventivo: Se registraron más de 6 millones de dominios futuros generados por el DGA, redirigiendo el tráfico a sinkholes controlados
3. Orden judicial: Tribunal del Distrito Este de Nueva York autorizó la toma de control de la infraestructura C&C en EE.UU.
4. Coordinación internacional: CERTs y ISPs de 35 países notificaron a los propietarios de máquinas infectadas
5. Resultado: La botnet perdió la capacidad de recibir comandos. Sin C&C activo, los bots quedaron huérfanos

Comparación técnica

Característica	Rustock (2006-2011)	Necurs (2012-2020)
Modo kernel	Driver polimórfico monolítico	Minifilter driver modular
Ocultación	DKOM + IRP hooking directo	Minifilter API (FltRegisterFilter)
Protección de archivos	Hook en NTFS dispatch table	Pre-operation callbacks en minifilter
Persistencia	Servicio de Windows + driver	Servicio + driver + módulos descargables
C&C	IPs hardcodeadas, HTTP	DGA (2048 dominios/día) + P2P backup
Escala (pico)	1-2 millones de bots	~6 millones de bots
Spam diario (pico)	30-40 mil millones	10-12 mil millones
Payloads adicionales	Solo spam	Locky, Dridex, TrickBot, DDoS, proxy
Anti-análisis	Polimorfismo en driver, anti-VM	Detección de sandbox, sleep prolongado
Causa de caída	IPs fijas, sin fallback	DGA crackeado, dominios pre-registrados

Evolución: de kernel stealth a persistencia en user-mode

Después del desmantelamiento de Necurs, las botnets de spam abandonaron progresivamente los rootkits de kernel. Las razones son múltiples:

Driver Signature Enforcement (DSE): Desde Windows Vista x64, Windows requiere que los drivers estén firmados por Microsoft o por una CA de confianza. Esto eleva el coste de desarrollar rootkits de kernel: se necesitan certificados robados o exploits para bypass de DSE.

PatchGuard (KPP): Kernel Patch Protection monitoriza estructuras críticas del kernel. Aunque no protege contra DKOM en listas de procesos, sí detecta modificaciones en la SSDT, IDT y otras tablas del sistema.

Virtualización (VBS/HVCI): Hypervisor-protected Code Integrity impide la carga de drivers no firmados incluso si se logra bypass de DSE.

Alternativas user-mode suficientes: Técnicas como process hollowing, DLL side-loading, y persistencia via tareas programadas proporcionan suficiente evasión sin los riesgos y la complejidad de operar en kernel-mode.

Las botnets modernas (Emotet, QBot) operan enteramente en user-mode. Pierden la invisibilidad absoluta que proporcionaba un rootkit de kernel, pero ganan en simplicidad, portabilidad y menor riesgo de causar BSOD (que alertaría al usuario).

Detección de rootkits de spam botnets

Verificación de drivers

Herramientas y técnicas:

1. Enumeración de drivers cargados:
   - DriverQuery /v (lista drivers con estado y tipo)
   - Comparar con lista de minifilters: fltMC.exe filters

2. Verificación de firmas:
   - sigcheck.exe -e -u C:\Windows\System32\drivers\*.sys
   - Flags: -u muestra solo drivers sin firma válida

3. Análisis de minifilters:
   - fltMC.exe instances (muestra instancias activas por volumen)
   - Altitude sospechosa: valores fuera de rangos documentados por MS

4. Volatility (análisis de memoria):
   - vol.py -f memory.dmp windows.modules   (drivers cargados)
   - vol.py -f memory.dmp windows.driverscan (scan por pool tags)
   - Comparar ambos: driver en driverscan pero no en modules = oculto

Detección de anomalías de red

Los bots de spam generan patrones de red característicos:

• Volumen SMTP anómalo: Una estación de trabajo que establece cientos de conexiones SMTP (puerto 25/587) por hora es sospechosa
• Resolución DNS masiva: El DGA genera miles de consultas DNS a dominios inexistentes (NXDOMAIN). Un ratio alto de NXDOMAIN desde un endpoint es indicador de DGA
• Conexiones a IPs en listas negras: Correlacionar IPs de destino con feeds de reputación (Spamhaus, abuse.ch Feodo Tracker)

Indicadores en el registro

Claves de registro comunes (Necurs):

HKLM\SYSTEM\CurrentControlSet\Services\{nombre_aleatorio}
  Type: 1 (SERVICE_KERNEL_DRIVER)
  Start: 1 (SERVICE_SYSTEM_START)
  ImagePath: \SystemRoot\System32\drivers\{nombre_aleatorio}.sys
  
Verificar:
  - Servicios de tipo kernel driver con nombres aleatorios
  - Drivers sin descripción ni compañía en sus metadatos
  - Timestamps de creación recientes en drivers del sistema

Mapeo MITRE ATT&CK

Técnica	ID	Uso en Rustock/Necurs
Rootkit	T1014	Driver de kernel para ocultar procesos y archivos del bot
Boot or Logon Autostart Execution: Kernel Modules and Extensions	T1547.006	Driver cargado como servicio del sistema al inicio
Masquerading	T1036	Nombres de driver que imitan drivers legítimos de Windows
Impair Defenses: Disable or Modify Tools	T1562.001	Minifilter bloquea acceso de AV a archivos del bot
Dynamic Resolution: Domain Generation Algorithms	T1568.002	Necurs DGA generando 2048 dominios diarios para C&C
Application Layer Protocol: Web Protocols	T1071.001	HTTP/HTTPS para comunicación con C&C
Email Collection	T1114	Recolección de contactos para listas de spam
Phishing: Spearphishing Attachment	T1566.001	Distribución de Locky/Dridex via adjuntos maliciosos (Necurs)
Direct Kernel Object Manipulation	(custom)	Rustock: DKOM para ocultar driver de lista de módulos
Proxy: Multi-hop Proxy	T1090.003	Necurs: módulo proxy para retransmitir tráfico

Lecciones para la defensa

1. Monitorizar tráfico SMTP saliente. Ninguna estación de trabajo debería enviar correo directamente por puerto 25. Bloquear SMTP saliente excepto desde servidores de correo autorizados elimina la utilidad de los bots de spam.

2. Analizar ratios de NXDOMAIN. Un endpoint con ratio alto de consultas DNS sin respuesta es candidato a infección por malware con DGA. Soluciones DNS como Pi-hole o servidores DNS corporativos con logging facilitan la detección.

3. Auditar minifilters regularmente. fltMC.exe filters lista los minifilters activos con su altitude. Un minifilter desconocido con altitude fuera de los rangos documentados por Microsoft requiere investigación.

4. Verificar integridad de drivers. Todos los drivers en C:\Windows\System32\drivers\ deben tener firma digital válida. sigcheck -u -e de Sysinternals identifica drivers sin firma.

5. Baseline de drivers del sistema. Mantener un inventario de drivers legítimos permite detectar la aparición de drivers nuevos no autorizados.

Fuentes y referencias

• Microsoft Digital Crimes Unit. "Operation b107: Rustock Botnet Takedown." Microsoft On the Issues, marzo 2011
• Microsoft. "Necurs botnet takedown." Microsoft Blog, marzo 2020
• Symantec Security Response. "Trojan.Rustock Technical Analysis." Symantec Threat Intelligence, 2008
• FireEye. "Necurs Botnet: A Pandora's Box of Malicious Spam." FireEye Threat Research, 2017
• BitSight. "Necurs DGA Analysis and Sinkholing." BitSight Research, 2020
• Stone-Gross, B. et al. "Your Botnet is My Botnet: Analysis of a Botnet Takeover." ACM CCS, 2009
• MITRE ATT&CK. "Software: Necurs (S0242)." MITRE Corporation
• Matrosov, A., Rodionov, E., Bratus, S. "Rootkits and Bootkits: Reversing Modern Malware." No Starch Press, 2019
• US-CERT. "Alert TA17-293A: Advanced Persistent Threat Activity Targeting Energy and Other Critical Infrastructure Sectors." CISA, 2017