Notifications
Clear all
Topic starter
06/09/2026 9:34 am
TL;DR: DLL sideloading lets attackers load malicious code alongside a legitimate executable by exploiting Windows DLL search order behaviour, as Airlock Digital explains in its CPU-Z incident walkthrough. The core lesson is that allowlisting has to cover runtime-loaded components as well as the signed primary binary, because trust at launch does not guarantee trust at execution.
NHIMG editorial — based on content published by Airlock Digital: Understanding supply chain attacks using DLL sideloading
Questions worth separating out
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.
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.
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.
Practitioner guidance
- Enforce library-level allowlisting Extend application control so the policy checks runtime-loaded DLLs, not only the parent executable.
- 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.
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.
👉 Read Airlock Digital's analysis of the CPU-Z DLL sideloading attack →
DLL sideloading and supply chain abuse: are your controls keeping up?
Explore further
06/09/2026 9:34 am
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.
A question worth separating out:
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.
👉 Read our full editorial: DLL sideloading in supply chain attacks: what practitioners need to know
