Control a privileged DLL, helper or configuration load

Needs: Actual controlled resolution path, compatible name/architecture/exports and a reliable privileged load trigger

Windows commands

REM Baseline
icacls "C:\Path\To\Application"
sc.exe qc SERVICE
reg query "HKLM\SYSTEM\CurrentControlSet\Control\Session Manager\KnownDLLs"
reg query "HKLM\SYSTEM\CurrentControlSet\Control\Session Manager" /v SafeDllSearchMode

Modern DLL resolution can apply redirection, API sets, side-by-side manifests, loaded modules, KnownDLLs, package dependencies and application-specific search flags before ordinary directories. Safe DLL search mode is enabled by default. In a suitable lab, Procmon filters for the process, CreateFile, .dll, and NAME NOT FOUND provide decisive runtime evidence; low-privilege remote use may be unavailable.

Verify → Verify the actual loaded path and privileged effect; a file placed on disk is not a completed chain.

If it fails → Wrong ABI/exports, earlier trusted resolution or no load trigger blocks the method. More detail ↓

If → then

An existing C/C++ or platform-specific PoC matches the candidate → Compile and minimally adapt an existing native or memory-corruption PoC
Needs: Correct compiler/target architecture, runtime dependencies, documented payload constraints and validated exploit-specific constants
A privileged object appears writable or an ACL tool reports a useful right → Prove effective file, registry and service-object permissions
Needs: Correct trustee/token, object type and effective rights including parents and deny entries
A new Windows session or claimed administrator/SYSTEM transition → Establish Windows token, host and process context
Needs: A functioning command channel and the actual effective token/process context

No useful finding → another task in this topic. Failed check → resolve the failure before ruling out the path.

Explanation & examples

Control a privileged DLL, helper or configuration load

USE WHEN: A privileged application searches for a missing dependency or consumes writable configuration
STARTING ACCESS: A verified Windows foothold with a known token, integrity level and groups
RESULT: Verified privileged consumption of the chosen dependency

Recognize the clue

Investigate a privileged application with observed dependency failures; if permitted, filter its runtime file loads in Procmon before checking candidate directory ACLs.

Procmon, when accessible: filter the actual process; inspect requested .dll paths and NAME NOT FOUND results.
Record the exact requested filename and every searched location.
Then inspect the selected location's effective ACL with the owning procedure.

SYNTHETIC EXAMPLE OUTPUT

PROCESS CreateFile C:\SEARCH_PATH\missing.dll NAME NOT FOUND
Privilege and selected search order: not yet verified

Means: An actual requested missing dependency is stronger than guessing a DLL name, but does not prove an attacker-controlled resolution wins.

Confirm: Validate real privilege, search precedence/KnownDLLs/manifests, directory control, ABI/exports and a load trigger.

After validation: The privileged process selects the controlled compatible dependency: choose that load route.
Ruled out in this context: A trusted manifest/earlier location resolves it before the writable directory: reject that path.
Still inconclusive: No runtime visibility leaves loading behavior unresolved; retain it as a candidate rather than declaring hijack success.

Troubleshooting: Wrong ABI/exports, earlier trusted resolution or no load trigger blocks the method.

Additional prerequisite checks

icacls "C:\Path\To\Application"
reg query "HKLM\SYSTEM\CurrentControlSet\Control\Session Manager\KnownDLLs"

Confirm:

exact DLL/helper/config name and architecture;
privileged process actually requests it;
selected attacker-writable location precedes the legitimate resolution;
payload preserves required exports/behavior where necessary;
reliable trigger exists.

Modern DLL resolution can apply redirection, API sets, side-by-side manifests, loaded modules, KnownDLLs, package dependencies and application-specific search flags before ordinary directories. Safe DLL search mode is enabled by default. In a suitable lab, Procmon filters for the process, CreateFile, .dll, and NAME NOT FOUND provide decisive runtime evidence; low-privilege remote use may be unavailable.

Why it works

DLL loading can involve KnownDLLs, manifests, redirection, packages and explicit search flags before ordinary directories. A missing DLL name or writable directory alone does not establish selection.

Worked example · hypothetical

Observation: runtime evidence shows a privileged process requests a missing DLL. Test: verify the effective search order and writable candidate location. Illustrative output: a trusted manifest redirects the load elsewhere. Interpretation: reject that candidate and inspect another dependency.

New identity, privilege, host or route? Re-enumerate → All topic tasks →

Study guide ↗Full procedure ↗Cheatsheet ↗