Path & DLL hijacking
A veces el fallo no está en un servicio concreto sino en CÓMO Windows busca lo que ejecuta o carga. Si un proceso privilegiado llama a un programa o a una DLL por su nombre (sin ruta absoluta), y tú controlas un sitio donde Windows va a buscar primero, ganas.
📂Carpeta del %PATH% escribible
Si una carpeta del PATH del sistema es escribible por ti, y un proceso privilegiado invoca un comando por su nombre (sin ruta completa), Windows lo busca por el PATH en orden. Pones tu binario con ese nombre en tu carpeta y se ejecuta con los privilegios del proceso.
echo %PATH% (o $env:PATH) -> revisa cada carpeta.icacls sobre cada una -> ¿alguna con (W)/(F) para ti?comando.exe con el nombre del binario que el proceso SYSTEM llama por nombre.🧩DLL search order hijacking
Cuando una app carga una DLL por nombre, Windows la busca en un ORDEN (carpeta de la app, System32, PATH...). Si puedes escribir en una carpeta que se consulta ANTES que la legítima, tu DLL gana.
| Detecta | Process Monitor (procmon) filtrando por 'NAME NOT FOUND' en *.dll -> DLLs que la app busca y no encuentra. |
| Fabrica la DLL | msfvenom -f dll, o una DLL con DllMain que lance tu payload. |
| Colócala | en la primera ruta del orden de búsqueda donde tengas escritura -> se carga con los privilegios del proceso. |
👻Phantom DLL
Caso especial: un proceso de SYSTEM intenta cargar una DLL que no existe en ningún sitio (DLL "fantasma"). Si localizas dónde la busca y puedes escribir ahí, la "creas" tú con tu código. Muy limpio: no rompes nada legítimo.