A technique where a legitimate application loads a malicious library because of how Windows searches for DLL dependencies. The attacker borrows the trust of signed software to execute code, which can bypass simple reputation checks and make malicious activity look like normal program behaviour.
Expanded Definition
DLL side-loading is a Windows execution pattern where a trusted application is induced to load an attacker-controlled library from a location the program checks before the legitimate copy. In NHI and endpoint security discussions, it matters because the malicious code inherits the host process trust boundary and can blend into normal software behaviour.
Definitions vary across vendors on whether side-loading, search order hijacking, and DLL proxying are separate techniques or overlapping labels, but the operational concern is the same: an attacker places a rogue library where a signed executable will find it first. This is closely related to application trust abuse, not credential theft in the narrow sense, and it often creates a path for follow-on actions such as token theft, command execution, or persistence. The NIST Cybersecurity Framework 2.0 frames the broader need to identify, protect, detect, and respond to such software trust failures.
The most common misapplication is treating DLL side-loading as a simple malware delivery problem, which occurs when defenders focus on the file dropped rather than the trusted process and path resolution conditions that make execution possible.
Examples and Use Cases
Implementing detection and prevention rigorously often introduces compatibility and tuning constraints, requiring organisations to weigh software continuity against stricter library loading controls.
- A signed desktop application launches from a writable directory and loads a malicious DLL placed beside it, allowing code execution under the process context.
- An attacker uses a legitimate update utility to load a rogue library during startup, gaining persistence without replacing the main executable.
- A developer workstation with exposed tokens becomes a staging point for side-loading, turning a trusted build tool into a launchpad for lateral movement. The JetBrains GitHub plugin token exposure illustrates how trusted software ecosystems can become attack surfaces when trust is misplaced.
- A security product flags the signed binary as benign while missing the malicious DLL in the same directory, demonstrating why path-based allowlisting alone is insufficient.
- Operators harden Windows search order, restrict writable application directories, and monitor unexpected module loads to reduce abuse opportunities.
Why It Matters in NHI Security
DLL side-loading is especially dangerous in NHI environments because service accounts, automation runners, and agentic workloads often execute with broad privileges and limited interactive oversight. When a trusted binary loads a malicious library, the resulting activity can impersonate a legitimate workload, creating confusion in attribution, logging, and incident response. This is why side-loading belongs in both endpoint hardening and NHI governance: it is not only a malware issue, but also a trust-boundary failure that can expose secrets, API keys, and deployment credentials.
NHIMG research shows that 80% of identity breaches involved compromised non-human identities such as service accounts and API keys, and 97% of NHIs carry excessive privileges, which means a single compromised execution path can have outsized blast radius. The same governance gaps that leave secrets scattered across code and CI/CD tools also increase the impact of a side-loaded process. Practical defence requires module-load monitoring, least privilege, protected search paths, and rapid rotation of any secrets touched during compromise, aligned with NHI governance principles described in the Ultimate Guide to Non-Human Identities and the NHI risk patterns seen in JetBrains GitHub plugin token exposure.
Organisations typically encounter DLL side-loading as a root cause only after an apparently trusted process has already executed malicious code, at which point containment, revocation, and forensic reconstruction become operationally unavoidable.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
OWASP Non-Human Identity Top 10 address the attack and risk surface, while NIST CSF 2.0 and NIST Zero Trust (SP 800-207) set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| OWASP Non-Human Identity Top 10 | NHI-02 | Side-loading often enables secret exposure and trusted-process abuse. |
| NIST CSF 2.0 | PR.AC-4 | Least-privilege and access control limit the blast radius of loaded malicious code. |
| NIST Zero Trust (SP 800-207) | Zero Trust requires verifying trusted software paths and runtime behaviour continuously. |
Restrict service account rights and monitor unexpected module loads under access control reviews.
Related resources from NHI Mgmt Group
- Why do MCP tools need server-side policy checks instead of token-only controls?
- Should organisations allow AI agents to perform side-effecting actions through MCP?
- What breaks when prompt loading or deserialisation is not constrained?
- How should security teams implement authentication in React Router apps with server-side rendering?
Deepen Your Knowledge
Reviewed and updated by the NHIMG editorial team on June 23, 2026.
NHI Mgmt Group — the #1 independent authority on Non-Human Identity, IAM, and Agentic AI security. nhimg.org
