DLLHijackHunter

Por ProjectMerai

Descubrimiento, Validación y Confirmación Automatizada de DLL Hijacking
Convirtiendo configuraciones locales erróneas en rutas de ataque armadas y confirmadas.

Descripción General

DLLHijackHunter es una herramienta automatizada de detección de DLL hijacking en Windows que va más allá del análisis estático. Descubre, valida y confirma oportunidades de DLL hijacking mediante un pipeline de múltiples fases:

1. Descubrimiento — Enumera binarios en servicios, tareas programadas, elementos de inicio, objetos COM y vectores de bypass de UAC AutoElevate
2. Filtración — Elimina falsos positivos mediante puertas inteligentes duras y blandas
3. Confirmación Canary — Despliega un DLL canary inofensivo y dispara el binario para demostrar que el hijack funciona
4. Puntuación e Informes — Clasifica los hallazgos según su explotabilidad con un sistema de confianza por niveles

La mayoría de las herramientas de DLL hijacking se detienen en "este DLL podría ser secuestrable". DLLHijackHunter intenta validarlo, contrastarlo con inteligencia de exploits conocida y confirmar rutas de ejecución reales cuando sea posible.

Arquitectura

flowchart TB
    subgraph Phase1["Fase 1: Descubrimiento"]
        SE["Motor Estático<br/>Servicios, Tareas, Inicio,<br/>COM, Claves Run"]
        AE["Motor AutoElevate<br/>Manifiesto + Bypass UAC COM"]
        PE["Analizador PE<br/>Tablas de Importación, Cargas Diferidas,<br/>Manifiestos, Exportaciones"]
        ETW["Motor ETW<br/>Monitoreo de Carga de DLL<br/>en Tiempo Real"]
        SO["Calculador de<br/>Orden de Búsqueda"]
    end

    subgraph Phase2["Fase 2: Pipeline de Filtrado"]
        direction LR
        HG["Puertas Duras<br/>(Eliminación Binaria)"]
        SG["Puertas Blandas<br/>(Ajuste de Confianza)"]
    end

    subgraph Phase3["Fase 3: Verificación de Carga (--verify-load)"]
        LP["LoadProbe<br/>Prueba de carga en proceso hijo<br/>DLL de prueba colocado y eliminado"]
    end

    subgraph Phase4["Fase 4: Canary"]
        CB["Constructor de DLL Canary"]
        TE["Ejecutor de Disparo"]
        VF["Verificación"]
    end

    subgraph Phase5["Fase 5: Salida"]
        SC["Puntuador por Niveles"]
        RC["Informe de Consola"]
        RJ["Informe JSON"]
        RH["Informe HTML"]
    end

    SE --> PE --> SO
    AE --> PE
    ETW --> SO
    SO --> Phase2
    HG --> SG
    Phase2 --> Phase3
    Phase3 --> Phase4
    CB --> TE --> VF
    Phase4 --> Phase5

Características Clave

Cobertura de Tipos de Hijack

Las entradas de depurador IFEO se enumeran y el binario referenciado se analiza en busca de importaciones de DLL, pero no existe un tipo de hijack dedicado de bypass de IFEO/KnownDLL — esos no se anuncian como detecciones independientes.

Descubrimiento de Bypass de UAC

DLLHijackHunter incluye descubrimiento dedicado de bypass de UAC:

• AutoElevate de Manifiesto — Escanea System32 y SysWOW64 en busca de EXEs con <autoElevate>true</autoElevate> en manifiestos incrustados
• AutoElevación COM — Escanea HKLM\SOFTWARE\Classes\CLSID en busca de objetos COM con Elevation\Enabled=1
• Simulación de Side-Load — Para binarios AutoElevate que no llaman a SetDllDirectory o SetDefaultDllDirectories, simula la ruta de ataque "copiar EXE a carpeta escribible + soltar DLL"

Base de Conocimiento de Vulnerabilidades Dirigidas

• Mapeo de vulnerabilidades dirigidas — Contrasta las importaciones descubiertas con una instantánea incluida del conjunto de datos HijackLibs (≈590 entradas de DLL documentadas que abarcan ≈700 ejecutables vulnerables), incrustada como Resources/hijacklibs.json. Una coincidencia aumenta la confianza y vincula el hallazgo a su página de referencia de HijackLibs; la ausencia de coincidencia no significa nada. El conjunto de datos está basado en datos — actualícelo re-descargando https://hijacklibs.net/api/hijacklibs.json sobre ese recurso (sin cambios de código necesarios). Conjunto de datos © el proyecto HijackLibs y sus contribuyentes.
• Explotación automatizada de PATH — Evalúa carpetas PATH escribibles y genera candidatos de hijack para un mapa curado de servicios nativos de Windows conocidos por buscar PATH en busca de DLLs faltantes
• Búsqueda ampliada de DLLs fantasma — Busca una biblioteca de oportunidades de DLL fantasma de alto valor en múltiples categorías

Pipeline de Filtrado

El pipeline reduce los falsos positivos mediante dos etapas:

Puertas Duras

• Filtrado de esquema de conjuntos de API (api-ms-*, ext-ms-*)
• Filtrado de KnownDLL
• Validación de escribibilidad ACL relativa al atacante — una ruta cuenta como escribible solo si un principal no privilegiado (Users / Authenticated Users / Everyone, más cuentas de servicio sub-admin a prueba de fugas como LOCAL SERVICE/NETWORK SERVICE) tiene derechos de escritura efectivos. Crucialmente, esto se calcula independientemente del token bajo el que se ejecuta la herramienta, por lo que ejecutarse elevado no hace que System32/Program Files parezcan escribibles. Esto es lo que hace que las ejecuciones elevadas sean significativas para el triaje de LPE.

Puertas Blandas

• Penalización de manifiesto WinSxS
• Análisis de delta de privilegios
• Comprobaciones de mitigación de LoadLibraryEx
• Comprobaciones de validación de firma
• Penalizaciones por manejo elegante de errores

Confirmación Canary

En lugar de adivinar, DLLHijackHunter intenta demostrar que los hijacks funcionan:

sequenceDiagram
    participant H as DLLHijackHunter
    participant B as Constructor de DLL Canary
    participant T as Ejecutor de Disparo
    participant V as Binario Víctima

    H->>B: Construir DLL canary
    B->>B: Extraer canary precompilado<br/>(o compilar un proxy con MSVC)
    B-->>H: canary.dll + ruta del archivo de confirmación
    H->>H: Colocar DLL en la ruta de hijack
    H->>T: Disparar ejecución del binario
    T->>V: Iniciar servicio / ejecutar tarea / activar COM
    V->>V: Carga el DLL canary
    V-->>H: Escribe archivo de confirmación<br/>PID, privilegio, nivel de integridad
    H->>H: Registrar: CONFIRMADO
    H->>H: Limpiar DLL canary

El DLL canary:

• Se distribuye precompilado tanto para x64 como para x86, incrustado en el escáner, por lo que no se requiere compilador en el momento del escaneo. La arquitectura correcta se selecciona para coincidir con la bitness de la víctima y se extrae bajo demanda.
• Es auto-localizador: deriva la ruta de su archivo de confirmación en tiempo de ejecución desde su propia ruta de módulo cargado (%ProgramData%\DLLHijackHunter\canary_<hash>.confirm), por lo que un solo binario sirve para cada candidato. El escáner calcula el mismo hash desde la ruta de despliegue y sondea ese archivo.
• Utiliza un mecanismo de confirmación basado en archivos
• Captura metadatos de ejecución como usuario, nivel de integridad e indicadores de privilegio
• No contiene carga maliciosa; es estrictamente un mecanismo de detección y validación
• Vincula estáticamente el CRT, por lo que no tiene dependencia de tiempo de ejecución (ucrtbase/vcruntime) en el host víctima.

Los binarios incluidos se construyen a partir del código fuente auditable en src/DLLHijackHunter/Resources/canary_src.c y pueden regenerarse con Resources/build_canary.bat (requiere el toolchain C++ de MSVC; el escáner no).

Excepción de proxy funcional: Cuando un hijack de orden de búsqueda apunta a un DLL que existe y expone exportaciones, mantener el host vivo después de la confirmación requiere un proxy de reenvío de exportaciones, que se compila por DLL con MSVC (cl.exe, localizado mediante vswhere/vcvarsall). Si no hay toolchain presente, se usa el canary precompilado en su lugar — aún confirma la carga (DllMain se dispara) pero no reenvía exportaciones, por lo que el proceso host puede fallar después de que se registre la confirmación. Los candidatos de DLL fantasma y otros sin exportaciones no necesitan compilador en absoluto.

Firma: Los canaries incrustados no están firmados. Firmarlos con código (para que se carguen bajo políticas más estrictas y sean atribuibles) requiere un certificado de firma y se deja como un paso de tiempo de lanzamiento para el mantenedor.

Nota importante sobre el modo proxy/reenvío de exportaciones

Los canaries de proxy/reenvío de exportaciones son experimentales y de mejor esfuerzo. Algunos objetivos pueden fallar al cargarse correctamente o comportarse inesperadamente dependiendo de:

• exportaciones solo por ordinal
• nombres de exportación decorados
• discrepancias en convenciones de llamada
• suposiciones del cargador/tiempo de ejecución en el proceso objetivo

Eso significa que un canary proxy fallido no siempre implica que la ruta de hijack subyacente sea imposible.

Verificación de Orden de Carga (--verify-load)

Una verificación opt-in, de usuario estándar, que se sitúa entre el pipeline de filtrado y la fase canary. Para cada candidato aplicable, escribe brevemente un DLL de prueba benigno en la posición de hijack escribible, luego pregunta al cargador real de Windows — en un proceso hijo de corta duración — que resuelva el DLL por nombre. Dónde resuelve el cargador determina el veredicto:

• Victoria verificada — el cargador elige la posición escribible. La afirmación de orden de búsqueda está probada (esta corroboración permite que el hallazgo alcance el nivel Alto; la ejecución canary sigue siendo la única ruta a Confirmado).
• Pierde contra protegido — el cargador elige un KnownDLL, la copia de System32 o una copia redirigida por SxS en su lugar. La posición casi con certeza no es secuestrable, por lo que el candidato se degrada fuertemente. Esto captura los falsos positivos clásicos que un calculador estático de orden de búsqueda pasa por alto (por ejemplo, un "hallazgo" de .local/orden de búsqueda para ntdll.dll que KnownDLLs hace inexplotable).

Notas de diseño y seguridad:

• Se ejecuta en un proceso hijo para que un nombre ya cargado en el escáner no pueda cortocircuitar el resultado, y para que cualquier efecto secundario de carga o fallo quede aislado. No se requiere elevación.
• Cada prueba se coloca, resuelve y luego se elimina; cualquier archivo preexistente se respalda y restaura.
• Modela el ordenamiento moderno de LOAD_LIBRARY_SEARCH, por lo que solo se aplica a candidatos Fantasma / Orden de Búsqueda / Side-Load. Los candidatos .local, PATH y AppInit/AppCert usan mecánicas diferentes y se reportan como Omitidos.
• Escribe archivos transitoriamente en posiciones candidatas (impacto medio); déjelo desactivado para un triaje completamente pasivo y de solo lectura.

# Triaje de usuario estándar con orden de búsqueda verificado por cargador (sin canary, sin ETW)
.\DLLHijackHunter.exe --lpe-only --no-canary --no-etw --verify-load

Comparación

Uso

Requisitos Previos

• Windows 10/11 o Windows Server 2016+
• Runtime .NET 8.0 o 10.0 (o use una compilación autocontenida)
• Privilegios de administrador recomendados (requeridos para ETW, despliegue de canary y algunos disparadores de servicios)

Compilación

git clone https://github.com/ghostvectoracademy/DLLHijackHunter.git
cd DLLHijackHunter

# Compilar (archivo único autocontenido)
dotnet publish src/DLLHijackHunter/DLLHijackHunter.csproj `
    -c Release -r win-x64 --self-contained `
    -p:PublishSingleFile=true -o ./publish

# O use el script de compilación
.\build.ps1

Inicio Rápido

# Escaneo agresivo completo (recomendado, requiere admin)
.\DLLHijackHunter.exe --profile aggressive

# Escaneo seguro (sin soltar archivos, sin disparadores)
.\DLLHijackHunter.exe --profile safe

# Escaneo enfocado en bypass de UAC
.\DLLHijackHunter.exe --profile uac-bypass

# Apuntar a un binario específico
.\DLLHijackHunter.exe --target "C:\Program Files\MyApp\app.exe"

# Apuntar por nombre de archivo (coincidencia parcial)
.\DLLHijackHunter.exe --target notepad.exe

# Solo hallazgos confirmados
.\DLLHijackHunter.exe --profile redteam --format json -o report.json

Opciones de CLI

DLLHijackHunter — Detección Automatizada de DLL Hijacking

Opciones:
  -p, --profile <perfil>         Perfil de escaneo [predeterminado: aggressive]
                                   aggressive | strict | safe | redteam | uac-bypass
  -o, --output <ruta>            Ruta del archivo de salida (detecta formato automáticamente)
  -f, --format <formato>         Formato de salida [predeterminado: console]
                                   console | json | html
  -t, --target <objetivo>        Apuntar a un binario, directorio o nombre de archivo específico
      --min-confidence <valor>   Umbral mínimo de confianza 0-100. Cuando se omite, se aplica
                                   el umbral propio de cada perfil; pasarlo lo anula.
      --no-canary                Deshabilitar confirmación canary
      --no-etw                   Deshabilitar descubrimiento en tiempo de ejecución ETW
      --verify-load              Verificar el orden de búsqueda con el cargador real (ver abajo).
                                   Usuario estándar; escribe transitoriamente una sonda benigna.
      --confirmed-only           Mostrar solo hallazgos confirmados por canary
      --lpe-only                 Caza estricta de LPE: ignorar System32/Program Files, mostrar
                                   solo vulnerabilidades escribibles por usuario estándar
      --log-file <ruta>          Escribir un registro de escaneo de diagnóstico en archivo
  -v, --verbose                  Salida detallada

Nota: --min-confidence solo se trata como una anulación cuando lo pasa explícitamente. De lo contrario, se usa el umbral del perfil seleccionado (por ejemplo, safe = 50%, strict = 80%).

Perfiles de Escaneo

Puntuación

Cada hallazgo recibe señales de confianza e impacto que se combinan en un nivel final de priorización.

Las consideraciones típicas de impacto incluyen:

• privilegio obtenido
• fiabilidad del disparador
• sigilo
• persistencia tras reinicio

La ejecución canary confirmada debe tratarse como la señal de validación más fuerte.

Limitación por niveles: los niveles Alto y Confirmado están reservados para hallazgos respaldados por una señal de prueba — un canary disparado, una observación de carga en tiempo de ejecución ETW o una coincidencia documentada en la base de conocimiento. Una coincidencia puramente estática de orden de búsqueda, por limpia que sea, está limitada a la parte superior del nivel Medio y se anota como Solo estático para que las heurísticas no verificadas nunca se presenten como de alta confianza.

Configuración recomendada de triaje

Debido a que la escribibilidad se evalúa relativa al atacante, tanto las ejecuciones elevadas como las de usuario estándar son significativas:

• Para el triaje de LPE, la configuración más confiable es una ejecución de usuario estándar con --lpe-only (y --no-canary si no hay compilador disponible) — cada hallazgo superviviente es genuinamente escribible por un principal no privilegiado.
• Las ejecuciones elevadas son necesarias para ETW y confirmación canary, y ahora están a salvo de la inversión histórica de "todo en System32 parece escribible".

Seguridad

DLLHijackHunter está diseñado para investigación de seguridad defensiva, validación en laboratorio, auditoría y simulación de red team en entornos autorizados.

Úselo solo en sistemas y redes que posea o para los que tenga autorización explícita de evaluación.

Notas operativas

• El modo canary escribe DLLs de prueba en ubicaciones candidatas
• Algunos disparadores pueden iniciar o detener brevemente servicios/tareas durante la validación
• Los canaries de proxy/reenvío de exportaciones pueden desestabilizar objetivos frágiles
• El perfil safe es el modo preferido para triaje en producción cuando no se aceptan soltar archivos ni disparadores

Salida

DLLHijackHunter admite:

• informes de consola
• exportación JSON
• exportación HTML

Flujo de trabajo recomendado:

1. ejecutar un escaneo amplio
2. revisar los hallazgos de alta confianza
3. usar confirmación canary selectivamente en rutas de alto valor
4. conservar la salida JSON/HTML para informes y triaje

Licencia

MIT

Créditos

Construido por ProjectMerai.