ZeroAccess/Sirefef: Anatomía del Rootkit que Construyó una Botnet de 9 Millones

Una de las botnets más grandes de la historia

Entre 2010 y 2013, ZeroAccess (también conocido como Sirefef o max++) infectó aproximadamente 9 millones de sistemas Windows en todo el mundo. No fue solo un rootkit sofisticado: fue una plataforma de distribución de malware completa, con un sistema de archivos oculto, una arquitectura de comando y control peer-to-peer descentralizada y un modelo de negocio que generaba decenas de miles de dólares diarios.

La combinación de un rootkit de kernel (primera generación) con una arquitectura P2P resistente a takedowns (segunda generación) hizo de ZeroAccess uno de los especímenes más estudiados por la industria de seguridad. Su desmantelamiento parcial en 2013 requirió una operación coordinada entre Microsoft, Europol y el FBI.

Cronología y contexto

Orígenes (2009-2010)

Las primeras muestras de ZeroAccess aparecieron a finales de 2009, inicialmente bajo el nombre "max++" por una cadena de depuración encontrada en sus binarios tempranos. El nombre "ZeroAccess" proviene del directorio \??\C:\Windows\$NtUninstallKB_GUID$\[randomnumber]\@ donde almacenaba componentes, que contenía una referencia a un device object llamado ZeroAccess.

El vector de infección inicial variaba: exploit kits (especialmente Blackhole), descargas troyanizadas de software pirata (keygens, cracks) y redirecciones desde sitios web comprometidos. ZeroAccess no explotaba vulnerabilidades zero-day propias; dependía de vectores de entrega ya establecidos.

Primera generación: rootkit de kernel (2010-2011)

ZeroAccess v1 era un rootkit de kernel completo para Windows x86. Instalaba un driver que operaba como un miniport filter, interceptando operaciones de I/O a nivel del subsistema de almacenamiento. Esta primera versión fue la más agresiva técnicamente.

Segunda generación: user-mode con autoprotección (2012-2013)

Hacia 2012, los autores de ZeroAccess abandonaron el componente de kernel. Windows x64 requería drivers firmados (Driver Signature Enforcement), y PatchGuard dificultaba la manipulación de estructuras del kernel. La segunda generación operaba íntegramente en user-mode pero compensaba con mecanismos de autoprotección extremadamente agresivos.

Disrupción y declive (2013-2014)

En diciembre de 2013, Microsoft DCU coordinó una operación de disrupción masiva. La botnet nunca fue completamente desmantelada (la naturaleza P2P lo impedía), pero su actividad declinó progresivamente durante 2014.

Arquitectura técnica: ZeroAccess v1

Driver de kernel (rootkit)

ZeroAccess v1 instalaba un driver de kernel que funcionaba como un Storage Miniport Filter. En lugar de hookear la SSDT o usar DKOM puro como FU Rootkit, ZeroAccess se posicionaba como un filtro en la pila de drivers de almacenamiento:

[Aplicaciones user-mode]
        │
[ntfs.sys]
        │
[ZeroAccess miniport filter]  ← intercepta aquí
        │
[disk.sys]
        │
[Hardware]

Este posicionamiento le daba control total sobre las operaciones de lectura y escritura en disco. Cuando una herramienta de seguridad intentaba leer los archivos del rootkit, el driver filtraba la solicitud y devolvía resultados vacíos o falsificados.

Filesystem oculto en Alternate Data Streams

La primera generación almacenaba sus componentes en Alternate Data Streams (ADS) de NTFS. Los ADS son flujos de datos alternativos asociados a un archivo pero invisibles para el Explorador de Windows y la mayoría de herramientas de listado de archivos:

C:\Windows\assembly\GAC\Desktop.ini
  └─ :config        (ADS: configuración cifrada)
  └─ :main_module   (ADS: módulo principal)
  └─ :plugin_001    (ADS: plugin de click fraud)
  └─ :plugin_002    (ADS: plugin de minería)

Las ventajas defensivas de los ADS para el malware eran múltiples: dir no los mostraba, muchos antivirus no escaneaban ADS en 2010, y el tamaño del archivo principal permanecía sin cambios (los ADS no afectan al tamaño visible del archivo host).

DKOM y manipulación del kernel

ZeroAccess v1 usaba DKOM (Direct Kernel Object Manipulation) para ocultar sus procesos y drivers, siguiendo la línea evolutiva de FU Rootkit. Desenlazaba sus estructuras EPROCESS de la lista ActiveProcessLinks y eliminaba sus entradas de PsLoadedModuleList.

Adicionalmente, el driver implementaba callbacks de notificación para detectar cuando herramientas de análisis se ejecutaban:

// ZeroAccess v1 registraba callbacks para detectar herramientas de análisis
// Pseudocódigo reconstruido de análisis de Sophos y Symantec

PsSetCreateProcessNotifyRoutine(ZaProcessCallback, FALSE);

VOID ZaProcessCallback(HANDLE ParentId, HANDLE ProcessId, BOOLEAN Create) {
    if (Create) {
        PEPROCESS process;
        PsLookupProcessByProcessId(ProcessId, &process);
        
        // Obtener nombre de imagen del proceso
        PUNICODE_STRING imageName = get_process_image_name(process);
        
        // Lista de herramientas bloqueadas
        if (match_blocklist(imageName)) {
            // Terminar el proceso antes de que pueda ejecutarse
            ZwTerminateProcess(ProcessId, STATUS_ACCESS_DENIED);
        }
        
        ObDereferenceObject(process);
    }
}

La lista de herramientas bloqueadas incluía: mbam.exe, procexp.exe, procmon.exe, wireshark.exe, gmer.exe, tcpview.exe y docenas más de herramientas de análisis y antivirus.

Arquitectura técnica: ZeroAccess v2

Migración a user-mode

ZeroAccess v2 abandonó el driver de kernel por razones pragmáticas. En Windows 7 x64 (ya ampliamente adoptado en 2012), cargar un driver sin firma requería desactivar Driver Signature Enforcement, algo que generaba alertas y complicaba la instalación silenciosa.

La segunda generación compensó la pérdida de privilegios de kernel con un sistema de autoprotección en user-mode que era, en muchos aspectos, más efectivo contra las herramientas de la época.

Directorio oculto bajo $Recycle.Bin

ZeroAccess v2 creaba un directorio oculto dentro de C:\$Recycle.Bin\S-1-5-18\ (el SID de la cuenta SYSTEM). Dentro de este directorio almacenaba sus componentes con nombres numéricos:

C:\$Recycle.Bin\S-1-5-18\$<hash_aleatorio>\
  ├── @             (ejecutable principal, módulo de servicio)
  ├── 00000001      (plugin: módulo P2P)
  ├── 00000002      (plugin: click fraud)
  ├── 00000004      (plugin: Bitcoin mining)
  ├── 00000008      (plugin: distribución spam)
  └── n             (directorio de configuración)

El archivo @ era el módulo principal que se instalaba como servicio de Windows. Los archivos numerados eran plugins descargados a través de la red P2P, cada uno con una funcionalidad específica de monetización.

Manipulación de ACLs

La autoprotección principal de v2 residía en la manipulación de Access Control Lists (ACLs) del sistema de archivos. ZeroAccess modificaba las ACLs de su directorio para denegar acceso a todos los usuarios y procesos excepto a sí mismo:

# ACL resultante en el directorio de ZeroAccess
# (observada mediante análisis forense, no como instrucción)
#
# Propietario: SYSTEM
# Permisos:
#   DENY  Everyone       - Full Control
#   DENY  Administrators - Full Control
#   DENY  SYSTEM         - Full Control (!)
#   ALLOW SYSTEM          - Special permissions (solo execute)

El detalle de denegar acceso incluso a SYSTEM y Administrators significaba que ni el usuario root del sistema ni los procesos con privilegios elevados podían listar, leer o borrar los archivos. Solo el proceso de ZeroAccess, que mantenía handles abiertos antes de aplicar las ACLs, podía operar con sus propios archivos.

Bloqueo de herramientas de seguridad

ZeroAccess v2 implementaba múltiples capas de bloqueo contra software de seguridad:

1. Modificación de hosts file. Añadía entradas que redirigían dominios de actualización de antivirus a 127.0.0.1, impidiendo que descargaran firmas nuevas.

2. Firewall rules. Creaba reglas en el Windows Firewall para bloquear las comunicaciones salientes de procesos de antivirus conocidos.

3. Monitorización activa de procesos. Un thread dedicado monitorizaba la lista de procesos y terminaba cualquier proceso que coincidiera con herramientas de seguridad conocidas. A diferencia de v1 (que usaba callbacks de kernel), v2 hacía polling periódico desde user-mode.

4. Corrupción de servicios de seguridad. Modificaba las claves de registro de servicios de Windows Defender y Windows Update para deshabilitar las actualizaciones automáticas:

# Claves de registro modificadas por ZeroAccess v2
# (documentadas por Microsoft para fines de detección y remediación)

HKLM\SYSTEM\CurrentControlSet\Services\WinDefend
  -> Start = 4 (disabled)

HKLM\SYSTEM\CurrentControlSet\Services\wuauserv
  -> Start = 4 (disabled)

HKLM\SYSTEM\CurrentControlSet\Services\MpsSvc
  -> Start = 4 (disabled)

Arquitectura P2P de comando y control

Diseño descentralizado

La innovación más significativa de ZeroAccess fue su arquitectura de C&C peer-to-peer. A diferencia de las botnets tradicionales que dependían de servidores C&C centralizados (fáciles de confiscar), ZeroAccess distribuía la coordinación entre todos los nodos infectados.

Cada bot ZeroAccess mantenía una lista de peers (otros bots conocidos) y se comunicaba directamente con ellos para recibir actualizaciones de plugins, comandos y nuevas listas de peers:

Bot A ──── Bot B ──── Bot C
  │  \    / │  \    / │
  │   Bot D   │   Bot E
  │  /    \ │  /    \ │
Bot F ──── Bot G ──── Bot H

No hay servidor central. Cada nodo es cliente y servidor.
Los plugins se propagan de peer a peer.

Protocolo de comunicación

ZeroAccess usaba UDP para la comunicación entre peers, en puertos altos que variaban entre versiones:

Versión	Puertos UDP	Uso
v2 (32-bit)	16464, 16465	Comunicación P2P
v2 (64-bit)	16470, 16471	Comunicación P2P

El protocolo implementaba varios tipos de mensajes:

• getL (get list): solicitar la lista de peers conocidos a otro bot
• retL (return list): responder con una lista de hasta 256 peers
• getF (get file): solicitar un plugin por su ID numérico
• retF (return file): transferir el contenido del plugin solicitado
• newL (new list): propagar una lista actualizada de peers

Los mensajes estaban cifrados con una clave RC4 hardcodeada en el binario. La clave variaba entre versiones, lo que efectivamente creaba redes P2P separadas para las variantes x86 y x64.

Sistema de plugins

La arquitectura modular de ZeroAccess permitía a los operadores distribuir nuevas capacidades sin reinfectar los sistemas. Cada plugin tenía un ID numérico y una versión. Cuando un bot recibía un plugin con versión superior a la que tenía localmente, lo instalaba automáticamente:

Plugin ID | Función                    | Impacto
----------|----------------------------|--------
00000001  | Módulo P2P core            | Comunicación entre bots
00000002  | Click fraud                | Simular clicks en anuncios
00000004  | Bitcoin mining             | Minar BTC con GPU/CPU
00000008  | Spam distribution          | Enviar spam masivo
00000010  | Trojan Downloader          | Descargar malware adicional

Monetización

Click fraud

El mecanismo principal de ingresos. ZeroAccess simulaba tráfico web legítimo para generar clicks en anuncios de pago por click (PPC):

1. El plugin descargaba una lista de URLs de destino desde la red P2P
2. Abría instancias ocultas de Internet Explorer (sin ventana visible)
3. Navegaba a las URLs de destino, que contenían anuncios
4. Hacía click automáticamente en los anuncios
5. Simulaba comportamiento humano (movimientos de ratón aleatorios, delays entre clicks)

Según estimaciones de Symantec (2013), ZeroAccess generaba aproximadamente 100.000 USD diarios en ingresos por click fraud, afectando principalmente a redes publicitarias como Google AdSense y Microsoft adCenter.

Minería de Bitcoin

El plugin de minería usaba los recursos de CPU y GPU de las máquinas infectadas para minar Bitcoin. En 2011-2012, cuando la dificultad de minería de Bitcoin era significativamente menor, una botnet de millones de sistemas podía generar cantidades relevantes de BTC.

El impacto para las víctimas era doble: consumo eléctrico elevado y degradación del rendimiento del sistema. Muchos usuarios detectaban la infección precisamente por la ralentización causada por la minería intensiva.

Escala de la infección

Estimaciones de tamaño

Las cifras variaban según la fuente y el momento de la medición:

Fuente	Fecha	Sistemas infectados
Sophos	2012	~9 millones acumulados
Symantec	2013	~1.9 millones activos
Microsoft	2013	~2 millones activos (pre-disrupción)
Kindsight (Sandvine)	2012	~2.2 millones activos en EE.UU.

La discrepancia entre "acumulados" y "activos" se explica por la rotación: sistemas reinstalados, formateados o desinfectados dejaban la botnet, mientras nuevas infecciones la mantenían. El pico de 9 millones de Sophos refiere al total histórico de infecciones únicas, no a la botnet activa simultáneamente.

Distribución geográfica

ZeroAccess tenía presencia global, con concentración en EE.UU. (mayor base de usuarios Windows, mayor valor por click en redes publicitarias), Europa occidental (Alemania, Reino Unido, Francia, Italia) y Japón.

Operación de disrupción (diciembre 2013)

Coordinación multi-agencia

Microsoft Digital Crimes Unit (DCU) lideró la operación, coordinando con:

• Europol / European Cybercrime Centre (EC3): coordinación europea
• FBI: jurisdicción estadounidense
• A10 Networks: apoyo técnico en sinkholing

Enfoque técnico

La disrupción de una botnet P2P es fundamentalmente diferente a la de una botnet centralizada. No hay un servidor C&C que confiscar. La estrategia fue:

1. Ingeniería inversa del protocolo P2P. Microsoft y socios mapearon la topología de la red P2P durante meses antes de la operación.
2. Sinkholing masivo. Se inyectaron nodos controlados por Microsoft en la red P2P. Estos nodos respondían a peticiones getL con listas de peers que apuntaban a sinkholes, desviando gradualmente el tráfico.
3. Orden judicial (Civil Action No. 1:13-cv-01014). Microsoft obtuvo una orden del Tribunal del Distrito Oeste de Texas para tomar control de dominios asociados y redirigir tráfico.
4. Bloqueo de actualizaciones de plugins. Al controlar nodos de la red, se impedía la distribución de nuevos plugins.

Resultado

La operación degradó significativamente la capacidad operativa de ZeroAccess, pero la naturaleza descentralizada de la red P2P impidió un desmantelamiento completo. Los nodos que no contactaron los sinkholes podían seguir operando y eventualmente reconstruir la red. Sin embargo, la combinación de la disrupción técnica con las actualizaciones de firmas de antivirus redujo la botnet a una fracción de su tamaño original durante 2014.

Detección y análisis forense

Indicadores de ZeroAccess v1

• Driver de kernel no firmado en la pila de storage miniport filters
• Alternate Data Streams anómalos en archivos de sistema
• Procesos ocultos detectables mediante Volatility psscan vs pslist
• Callbacks de notificación de procesos registrados por drivers sospechosos

Indicadores de ZeroAccess v2

• Directorios anómalos bajo C:\$Recycle.Bin\S-1-5-18\ con ACLs restrictivas
• Archivos con nombres numéricos (000000XX) en directorios protegidos
• Tráfico UDP saliente en puertos 16464, 16465, 16470 o 16471
• Servicios de seguridad deshabilitados (Windows Defender, Windows Update)
• Entradas en hosts file bloqueando dominios de actualización de antivirus
• Alto consumo de CPU/GPU sin proceso visible responsable (indicativo de minería)

Análisis con Volatility

# Detectar drivers ocultos de ZeroAccess v1
vol3 -f memory.dump windows.driverscan
vol3 -f memory.dump windows.modules

# Comparar para identificar drivers en driverscan pero no en modules
# (driver oculto de PsLoadedModuleList por DKOM)

# Detectar callbacks sospechosos
vol3 -f memory.dump windows.callbacks

# Buscar procesos ocultos
vol3 -f memory.dump windows.psscan
vol3 -f memory.dump windows.pslist
# Diferencias entre ambos = procesos ocultos por DKOM

Reglas de red

# Regla Snort/Suricata para tráfico P2P de ZeroAccess
# (uso defensivo: detección en perímetro de red)
# Puertos UDP conocidos de ZeroAccess v2
alert udp $HOME_NET any -> $EXTERNAL_NET 16464:16471 (
  msg:"MALWARE ZeroAccess P2P Traffic Detected";
  threshold: type both, track by_src, count 10, seconds 60;
  classtype:trojan-activity;
  sid:2013001; rev:1;
)

Mapeo MITRE ATT&CK

Técnica	ID	Uso en ZeroAccess
Rootkit	T1014	v1: driver kernel-mode con DKOM y storage filter
Hide Artifacts: Hidden Files and Directories	T1564.001	Filesystem oculto en ADS (v1) y $Recycle.Bin (v2)
File and Directory Permissions Modification	T1222	v2: ACLs restrictivas que bloquean acceso a todos
Impair Defenses: Disable or Modify Tools	T1562.001	Terminar procesos AV, modificar hosts, deshabilitar servicios
Application Layer Protocol	T1071	Protocolo P2P personalizado sobre UDP
Non-Standard Port	T1571	Puertos UDP 16464-16471 para C&C P2P
Resource Hijacking	T1496	Minería de Bitcoin con recursos de la víctima
Click Fraud	T1497 (proxy)	Simulación de clicks en anuncios PPC
Boot or Logon Autostart Execution: Registry Run Keys	T1547.001	Persistencia como servicio de Windows
Modify Registry	T1112	Deshabilitar Windows Defender y Windows Update
System Binary Proxy Execution	T1218	Inyección en procesos legítimos de Windows
Peer-to-Peer C2	T1090.003	Arquitectura P2P descentralizada sin servidor central

Lecciones defensivas

1. Las botnets P2P requieren estrategias de disrupción distribuida. Confiscar un dominio o servidor no funciona contra una red descentralizada. La disrupción requiere inyectar nodos controlados en la topología P2P y envenenar las listas de peers gradualmente.

2. La migración de kernel a user-mode no reduce la amenaza. ZeroAccess v2 demostró que un malware user-mode con buenas técnicas de autoprotección (ACLs, terminación de procesos, deshabilitación de servicios) puede ser igual de persistente que un rootkit de kernel. La defensa no puede asumir que "sin rootkit de kernel = fácil de eliminar".

3. La monetización determina la escala. ZeroAccess creció a millones de infecciones porque tenía un modelo de negocio claro (click fraud + mining) que justificaba la inversión en infraestructura. Los operadores reinvertían los ingresos en nuevos vectores de infección, creando un ciclo de crecimiento.

4. La coordinación entre industria y fuerzas de seguridad es necesaria pero insuficiente. La operación de Microsoft DCU fue exitosa en degradar la botnet, pero no en eliminarla. La resiliencia inherente a las redes P2P significa que la disrupción técnica debe complementarse con investigación criminal para identificar y procesar a los operadores.

---

Fuentes y referencias

• Wyke, J. "The ZeroAccess Botnet: Mining and Fraud for Massive Financial Gain." Sophos Technical Paper, 2012.
• Wyke, J. "ZeroAccess." Virus Bulletin Conference Paper, 2012.
• Symantec Security Response. "ZeroAccess Indepth." Symantec White Paper, 2013.
• Microsoft Digital Crimes Unit. "Microsoft, the FBI, Europol and industry partners disrupt the notorious ZeroAccess botnet." Microsoft Blog, 5 diciembre 2013.
• Neville, A. & Gibb, R. "ZeroAccess/Sirefef: A Technical Analysis." Symantec, 2013.
• Matrosov, A., Rodionov, E. & Bratus, S. "Rootkits and Bootkits: Reversing Modern Malware." No Starch Press, 2019.
• Sikorski, M. & Honig, A. "Practical Malware Analysis." No Starch Press, 2012.
• MITRE ATT&CK. "Rootkit (T1014)." https://attack.mitre.org/techniques/T1014/
• MITRE ATT&CK. "Impair Defenses (T1562)." https://attack.mitre.org/techniques/T1562/
• Microsoft. "Civil Action No. 1:13-cv-01014: Microsoft Corp. v. John Does 1-8." U.S. District Court, Western District of Texas, 2013.