Reduce the risk by controlling library search paths, using signed or trusted libraries, and removing write access to directories that the loader searches. Attackers abuse dynamic linker behaviour to load malicious libraries instead of the intended ones, so defenders should watch for unusual library resolution, new DLLs or shared objects, and path manipulation.
How dynamic linker hijacking works in practice
dynamic linker hijacking happens when an application asks the loader for a library and the loader finds an attacker-controlled copy first, or accepts a malicious library from a writable location. The security problem is not just the bad library itself, but the trust the runtime places in search order, path resolution, and directory permissions. That makes execution flow, not just code content, the real target.
Search-order problems can appear as DLL side loading on Windows, shared library injection on Unix-like systems, or path hijacking through environment variables and weakly controlled directories. Persistence Techniques Guide covers these execution-path abuses because the same weakness often supports both initial compromise and persistence.
The key practical distinction is whether the loader can be influenced before the intended library is resolved. If an attacker can place a library in a searched directory, alter a path, or exploit an unsafe lookup rule, the loader may bind to the wrong binary even when the application itself is otherwise legitimate.
Controls that reduce loader abuse
The most effective mitigations narrow what the loader is allowed to see and where it can look. Restrict library search paths to trusted locations, remove write access from directories the loader searches, and prefer signed or otherwise trusted libraries for sensitive software. Those controls matter because they reduce both accidental misloads and deliberate substitution attacks.
Use fixed absolute paths where the platform and application allow it, and avoid relying on current-working-directory or inherited environment values for library resolution. Where you cannot remove dynamic loading, validate that the application is resolving only the expected modules and that the directories involved are owned and protected by the correct administrative boundary.
Operational hardening also includes inventorying the modules a process should load and comparing that baseline to what actually appears at runtime. When a new DLL or shared object shows up in an unexpected directory, treat that as a control failure first, not merely as an application quirk.
Detection and response when hijacking is suspected
Monitor for unusual library resolution behaviour, unexpected module names, and path manipulation around processes that normally load a stable set of dependencies. On systems that support it, audit file creation in executable and library paths, especially directories that are writable by non-admin users or by the application service account.
Responder focus should be on confirming whether the process loaded the intended library, whether the malicious file remains on disk, and whether the same technique was used to gain persistence or credential access elsewhere. CISA cyber threat advisories are the right place to cross-check whether the observed behaviour matches a known exploitation pattern or broader active campaign guidance.
If compromise is confirmed, remove the rogue library, restore directory permissions, and review adjacent autorun or startup mechanisms that may have been used to reintroduce the payload. Where the hijacked process handles sensitive data or privileged operations, rotate any credentials, tokens, or keys the process could have exposed before trusting the host again.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
MITRE ATT&CK addresses the attack and risk surface, while CIS Controls v8 and NIST SP 800-53 Rev 5 set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| MITRE ATT&CK | T1574 — Hijack Execution Flow | Dynamic linker hijacking is an execution-flow hijack pattern. |
| Recommendation — Map library hijacking to T1574 and hunt for execution-flow abuse in loaded modules. | ||
| CIS Controls v8 | CIS-4 — Secure Configuration of Enterprise Assets and Software | Hardening library paths and directory permissions is secure configuration work. |
| CIS-8 — Audit Log Management | Detecting unusual library resolution depends on log and file activity visibility. | |
| Recommendation — Harden library paths, file permissions, and trusted software locations. Log and review anomalous module loads, path changes, and library file writes. | ||
| NIST SP 800-53 Rev 5 | CM-7 — Least Functionality | Limiting searched paths and loadable locations reduces unnecessary attack surface. |
| AC-6 — Least Privilege | Writable loader directories create privilege abuse opportunities. | |
| Recommendation — Restrict loader search locations and remove unnecessary load paths. Remove write access from directories used in library resolution. | ||
Practitioner Guidance
What to verify: Verify the full search path and the effective permissions on every directory the loader can reach, not just the application install folder. In practice, the most common miss is an apparently harmless writable path earlier in resolution order.
Decision rule: If a process loads libraries from a location that a lower-privileged user can modify, treat that as a priority fix even if no malicious DLL has been found yet. Exposure comes from the reachable path, not only from confirmed malware presence.
Common mistake: Teams often harden the executable while leaving dependent plugin, system, or runtime directories writable. That leaves the loader path open and preserves the attacker’s ability to redirect execution later.
Practitioner takeaway: Dynamic linker hijacking is prevented less by reactive malware cleanup than by making library resolution deterministic, non-writable, and observable.