DLL sideloading in supply chain attacks: what practitioners need to know

At a glance

What this is: This analysis explains how DLL sideloading turns a legitimate Windows executable into a delivery vehicle for malicious code by abusing runtime loading behaviour.

Why it matters: It matters to IAM, PAM, and security teams because trusted software execution can hide untrusted code paths, which weakens conventional application trust and control assumptions across endpoint and supply chain programmes.

👉 Read Airlock Digital's analysis of the CPU-Z DLL sideloading attack

Context

DLL sideloading is a technique where a trusted application loads a malicious library from an unexpected location because Windows resolves DLLs through a search order that can favour the local directory. That creates a control gap between what is signed, what is approved, and what is actually executed at runtime, which is why endpoint trust models need to account for the full load chain, not only the primary binary.

The identity intersection is indirect but real: when software loading becomes a trust boundary, the question is which code components are authorised to run under an application's identity and privileges. For security programmes that already use allowlisting, application control, or runtime policy, the CPU-Z case is a reminder that the executable identity is only part of the governance problem.

Key questions

Q: What breaks when DLL sideloading is not controlled in endpoint environments?

A: The assumption that a trusted application can only run trusted code breaks down. If Windows resolves a malicious library from a local directory before the intended system copy, the attacker can execute code through a legitimate process without replacing the main binary. That makes application trust incomplete unless library loading is governed as well.

Q: Why does DLL sideloading increase supply chain risk even when software is signed?

A: Signing the parent application does not guarantee that every dynamically loaded component is safe. An attacker can keep the signed executable intact and target the runtime loading path instead, which means the compromise happens through execution context rather than obvious binary tampering. Organisations need controls that govern both provenance and load behaviour.

Q: How can security teams tell whether allowlisting is actually stopping sideloading abuse?

A: Test whether an application still runs when an unapproved DLL is placed beside it and renamed to match an expected dependency. If the application loads it, the policy is too permissive. Effective allowlisting should block the library before execution, not just detect the file after the fact.

Q: Should organisations prioritise application control or code signing for DLL sideloading risk?

A: Application control should come first because it decides what can execute, while code signing only helps establish origin. A signed application can still become a delivery path for untrusted code if runtime-loaded libraries are not checked. The practical priority is to govern the full load chain and then use signing as one input to that decision.

Technical breakdown

How DLL search order creates a runtime trust gap

Dynamic-Link Library search order is the mechanism Windows uses to find required libraries when an application starts. If the application directory is searched before the intended system location, a malicious file placed beside a legitimate executable can be loaded instead of the expected DLL. The executable may remain signed and unmodified, which makes the abuse hard to spot with controls that only validate the primary binary. This is why sideloading is effective: the attack lives in the loading process, not in obvious tampering with the original program.

Practical implication: validate not only approved executables but also the DLL paths and load rules they rely on.

Why signed software can still execute untrusted code

Code signing proves that a binary came from a trusted publisher, but it does not automatically prove that every dependent module loaded at runtime is also trustworthy. In a sideloading scenario, the legitimate application becomes the launch point for untrusted code because the operating system accepts the library based on naming and search behaviour rather than publisher intent. This is a common blind spot in endpoint governance: application trust is often treated as a single decision when it is actually a chain of decisions about binaries, libraries, and loading context.

Practical implication: enforce policy on secondary load events, not just on the signed parent process.

Why deny by default breaks the sideloading chain

Deny by default allowlisting changes the control model from permissive execution to explicit authorisation. Instead of assuming a loaded component is acceptable unless blocked, the policy requires each binary and library to be approved before execution. That matters for sideloading because the malicious DLL never reaches the payload stage if the runtime-loaded component is untrusted. In practice, this is stronger than chasing indicators after the fact because it narrows the execution surface before malware can benefit from the trusted process context.

Practical implication: include runtime-loaded libraries in allowlisting policy and block unsigned components by default.

Threat narrative

Attacker objective: The attacker wants to execute malicious code through a trusted application path while avoiding obvious tampering with the primary executable.

1. Entry occurs when attackers place a malicious DLL next to a trusted executable so Windows resolves it during normal startup.
2. Escalation happens when the legitimate application loads the malicious library and executes attacker-controlled code under the application's trusted context.
3. Impact follows when the payload runs without replacing the main application binary, making the compromise harder to detect through simple file integrity checks.

NHI Mgmt Group analysis

DLL sideloading is a runtime trust problem, not just a software integrity problem. The main executable can remain legitimate while the attack succeeds through a companion library loaded at start-up. That shifts the governance question from 'is this program trusted' to 'which components can this program load under its authority'. Practitioners should treat runtime loading as part of the control boundary.

Runtime component authorisation is the named control gap this technique exploits. Security teams often validate the signed application and overlook the DLLs it resolves dynamically. That leaves a gap where trusted software becomes an execution wrapper for untrusted code. In endpoint governance terms, this is a policy failure around secondary loading paths, not a failure of binary trust alone. Practitioners should extend allowlisting and application control to dependent modules.

Supply chain defence has to include execution context, not only software provenance. A safe publisher, a valid signature, and a familiar application name do not guarantee safe runtime behaviour if local search order can be manipulated. This makes the case relevant to broader software trust programmes, including code signing policy and endpoint hardening. Practitioners should verify that trust decisions follow the execution chain all the way to loaded libraries.

Deny by default is more effective than reactive detection for sideloading abuse. Detection may still matter for hunting, but prevention depends on making untrusted modules fail before execution. That principle aligns with the broader logic of application control and is especially useful where attackers rely on obscure runtime behaviour rather than obvious malware indicators. Practitioners should block unapproved DLLs before payload execution can occur.

Software supply chain security increasingly depends on controlling what trusted applications are allowed to do at runtime. The industry has focused heavily on provenance, but this case shows that provenance alone is incomplete. The named concept here is runtime component authorisation: the ability to approve or deny every library a process may load. Practitioners should move toward controls that inspect the full load chain, not just the signed parent binary.

What this signals

DLL sideloading is a reminder that endpoint control failures often begin in places teams do not model as identity or authorisation decisions. Once a trusted process can load untrusted components, the security boundary shifts from the application name to the runtime context that the process inherits. That is why runtime trust should be reviewed alongside application control and privilege boundaries, not treated as a separate hygiene task.

Runtime component authorisation: this is the practical concept teams need to operationalise. If your endpoint policy only verifies the parent executable, you are trusting an incomplete execution path. Security teams should align application control with the principles in NIST SP 800-53 Rev 5 Security and Privacy Controls and the MITRE ATT&CK Enterprise Matrix, then test whether approved software can still be turned into a loading vector.

As organisations expand software distribution through internal tools, plugins, and update channels, the practical risk is not just malicious code appearing in the estate. It is trusted code being coerced into loading something else under a legitimate process identity. Teams should expect more abuse of runtime trust boundaries and build allowlisting, software inventory, and code provenance checks that follow the load chain.

For practitioners

• Enforce library-level allowlisting Extend application control so the policy checks runtime-loaded DLLs, not only the parent executable. Block unsigned or unapproved libraries even when the application itself is signed and trusted.
• Harden DLL search behaviour Reduce search-order exposure by removing writable locations from application load paths and applying Microsoft guidance on Dynamic-Link Library Security to sensitive endpoints.
• Audit trusted applications for sideload risk Inventory high-value Windows applications that load external modules and test whether a malicious file placed in the local directory would be loaded before the intended system copy.
• Monitor for suspicious sibling files Look for executables executing alongside unexpected DLLs, especially when the DLL name matches a known dependency but the hash, signer, or path does not.

Key takeaways

• DLL sideloading works because runtime loading can be manipulated even when the parent application is legitimate and signed.
• The control gap is secondary component authorisation, which means allowlisting must cover DLLs as well as executables.
• Endpoint teams should treat runtime trust as part of the software supply chain and block unapproved modules before execution.

Key terms

• DLL Sideloading: A technique where a legitimate executable loads a malicious library from a location the application checks before the real system path. It works because the program’s trust is inherited by the code it loads, which makes execution control as important as file reputation.
• Runtime Component Authorisation: Runtime component authorisation is the control decision that determines which libraries, modules, or plugins a trusted application may load while it is running. It extends application control beyond the parent binary so that secondary code paths are approved, denied, or constrained by policy.
• Deny By Default: Deny by default is an authorization rule that blocks access unless a policy explicitly permits it. It is the safer baseline for modern identity control because it limits accidental privilege expansion and makes every access grant visible, testable, and easier to review.
• DLL Search Order: DLL search order is the sequence Windows uses to locate a required library when an application starts. If unsafe search paths are permitted, an attacker can place a malicious file in a location that is checked before the intended system library and cause it to load.

What's in the full article

Airlock Digital's full article covers the operational detail this post intentionally leaves for the source:

• Step-by-step walkthrough of the CPU-Z DLL sideloading chain and why the attack succeeded.
• Practical explanation of how Airlock Digital's deny by default allowlisting breaks the load chain.
• Microsoft guidance on reducing DLL sideloading and search-order hijacking risk.
• IOC details including the malicious CRYPTBASE.DLL hash for defenders who need to hunt or validate exposure.

👉 The full Airlock Digital post covers the attack path, runtime loading behaviour, and prevention details.

Deepen your knowledge

NHI Foundation Level course, the industry's only accredited NHI security programme, covers NHI governance, machine identity security, and secrets management. It helps security practitioners connect identity controls to the broader runtime and supply chain risks their programmes now face.