DLL Sideloading (T1574.001)
What is DLL sideloading?
DLL sideloading is an attacker planting a malicious DLL where a legitimate, signed program will load it, so the payload runs inside a trusted process. MITRE ATT&CK now covers it under T1574.001, alongside DLL search order hijacking, redirection, phantom hijacking and substitution. The identifier T1574.002 no longer exists.
If you already knew the mechanism, that last sentence is the reason to keep reading. The behaviour has not changed. The reference has, and most of the field has not caught up yet.
The short version of the mechanism, for completeness: Windows resolves a DLL requested by name through an ordered list of locations, an attacker plants a file with the right name in a location that gets checked first, and the trusted program loads it. That is one sentence because it is the part everybody already covers well.
What follows is what actually changed in the framework, how it settles the sideloading-versus-hijacking question, why a hijacked process still looks normal, and what the current detection strategy watches.
DLL Sideloading Quiz
Test your knowledge about DLL Sideloading - maybe you already know everything about it.
What is DLL sideloading?
Explain It Like I'm 10
A courier comes to the same office every morning and picks up whatever parcel is sitting on the shelf by the door. They do not check who put it there. They just take what is on the shelf, because that is the job, and everyone trusts the courier. So if you want something carried out of the building, you do not need to fool the courier. You only need to get to the shelf first.
What happened to T1574.002
The DLL sub-techniques were merged. Three things establish it, and they are worth showing rather than asserting, because this is the kind of claim a reader should check:
- The old address is empty. A request to the T1574.002 technique page returns a response with no content in it. There is no page there.
- The parent's own list skips it. T1574's sub-technique list now holds twelve entries, and the identifiers run `.001`, then straight to `.004`. Both `.002` and `.003` are absent.
- The surviving entry absorbed the material. T1574.001 is now titled simply "DLL", at version 3.0, last modified 12 May 2026, and its body now describes sideloading, redirection, phantom hijacking and substitution together in one place.
The tactic mapping changed in the same revision, and this part travels further than one technique. T1574.001 now maps to Stealth and Execution. The tactic formerly called Defense Evasion is now titled Stealth, described as the adversary "trying to hide and conceal their actions, appearing as normal behavior". A separate tactic, Defense Impairment, now sits alongside it in the enterprise list. No source was found explaining the reasoning behind the split, so this article reports the change and does not speculate about it.
Nothing you built has stopped working
That needs saying immediately, because a note about merged techniques and renamed tactics reasonably prompts the thought that something broke.
Nothing did. A detection that matches a signed process loading a DLL from a non-standard directory is unaffected by a renumbering. So is one that alerts on a module load from a user-writable path, or a file creation followed by a load of the same name. The label moved. The behaviour did not. That is an inference from the record rather than a statement by MITRE, but it follows directly: the mechanisms enumerated at T1574.001 version 3.0 are the same behaviours the two older identifiers described, and the detection guidance keys on file creation, module load, registry modification and process creation, none of which knows what number it is filed under.
What actually needs updating
What does need attention is narrower and duller. An ATT&CK identifier is a string that lives in artifacts - in a rule's metadata, in a coverage matrix, in a report template, in a threat model somebody will open next quarter. Those are the places where `T1574.002` is still sitting, and those are what to go and fix.
One observation about how fast reference material goes stale, offered without any criticism of the people who wrote it: the highest-ranking explainer for this term, checked on 12 August 2026, carries a publication date of 12 May 2026, the same day as the revision, and does not mention the framework anywhere on the page.
Sideloading or hijacking? One sub-technique, several mechanisms
This is a real question that gets asked constantly, and the merge answers it structurally: they are not competing categories. They are named mechanisms inside one sub-technique.
Mechanism | What the attacker does | What it leaves behind |
|---|---|---|
DLL sideloading | Plants a payload beside a legitimate application and invokes that application, so the payload runs under a trusted process | A DLL sitting next to a signed executable outside its usual install path; a module load from that directory |
Search order hijacking | Places a DLL in a directory that the search order checks before the legitimate library's location | A module load resolving to an unexpected directory |
DLL redirection | Changes where the program looks, via the registry or a redirection file | A registry modification, or a redirection file appearing beside the application |
Phantom DLL hijacking | Supplies a DLL the program asks for but which does not exist on the system | A new file appearing at a path that previously produced a failed load |
DLL substitution | Replaces a valid DLL with one of the same name in the same location | A file with a known name whose hash no longer matches |
MITRE's own framing is the useful one: DLLs "are not malicious by nature", but they can be abused through side-loading, search order hijacking and phantom hijacking. The differences that matter are not taxonomic, they are evidentiary - each mechanism leaves a different trace, which is the third column.
One variant is worth naming because it appears nowhere else in the current explainer field: remote DLL hijacking, which can occur when a program sets its current directory to a remote location, such as a web share, before loading a DLL.
Why the process still looks normal
Here is the sentence that explains why this technique survives contact with endpoint tooling, from the technique record itself:
"Programs that fall victim to DLL hijacking may appear to behave normally because malicious DLLs may be configured to also load the legitimate DLLs they were meant to replace, evading defenses."
The consequence for a defender is worth being precise about. The application still works. The user notices nothing. The parent process is a signed, expected binary with a legitimate reason to be running, so process-lineage checks look clean and signature checks pass, because the thing that is signed is not the thing that is malicious.
Which is why the detectable fact is almost never the file itself. A DLL's name and hash are cheap for an attacker to change; where it was loaded from, and by what, is not. That distinction is the whole argument of the pyramid of pain, applied to one technique.
How to detect it
The merge shows up on the detection side too, and helpfully: one strategy now covers all of the mechanisms above. Detection strategy DET0201 describes correlating "file system modifications, registry changes, and module load telemetry to detect abnormal DLL behavior in trusted processes" - covering unexpected loads from non-standard directories, replacement, phantom insertion, redirection files and substitution in a single analytic.
The log sources are specific:
- File creation: Sysmon event 11.
- File metadata: Sysmon event 15.
- Module load: Sysmon event 7. If you only get one, this is the one.
- Registry key modification: Windows Security event 4657, which is what catches redirection.
- Process creation: Sysmon event 1, for the context around all of the above.
Those five give you the raw material. They do not, on their own, give you a rule, because a busy Windows estate loads DLLs from unusual places all day long for entirely legitimate reasons.
That is what the analytic's four tunable elements are for, and they are the part worth copying into your own design:
- Allowed DLL paths - the known-safe directories to suppress, with `C:\Windows\System32` as the obvious example.
- A process allowlist - the applications expected to load DLLs from non-standard locations. MITRE's own example is development tools, which is a useful reminder that the benign case is common rather than exotic.
- A correlation window - the interval within which file creation, registry changes and module load are treated as one event rather than three.
- A hash baseline - hashes for the legitimate DLLs, which is specifically what catches substitution, since substitution leaves the name and the path unchanged.
Without those four, this is a noisy signal. With them, it is a rule. That is the same shape as detecting abuse of remote monitoring tools: a trusted, signed thing is doing the work, and a baseline is what decides whether it should be.
Where this argument stops
Four bounds, and the first is the one that matters most.
- The label changed, not the behaviour. Stated again because it is the thing most likely to be misread: this is a reference update, not a security event. If your detections were behaviour-based, they still work. This is an inference from the record, clearly drawn but not a MITRE statement - the framework documented a merge, it did not comment on anyone's rules.
- DLLs are not the problem, and neither is the software. MITRE says plainly that DLLs are not malicious by nature. An application that can be sideloaded is not thereby negligent; the search order is a Windows behaviour, and the legitimate use of dynamic libraries is the entire reason the mechanism exists.
- The benign case is common. The analytic ships with an application allowlist because normal software genuinely loads DLLs from unusual paths. Anyone treating an unexpected load path as inherently malicious will spend their week closing tickets.
- This article's own sourcing has limits, and they are worth stating. The currency claim above rests on a check of four readable explainer pages on a single date - enough to report honestly, not enough to characterise the whole field. One result that promised real detection engineering could not be read at all, because the site serves a JavaScript shell, so nothing here characterises its contents. And no prevalence figure appears anywhere above, because none was found in a form worth citing.
Common questions
Which ATT&CK ID is DLL sideloading now?
T1574.001, titled "DLL", at version 3.0 and last modified 12 May 2026. It maps to the Stealth and Execution tactics. The identifier T1574.002 no longer resolves.
Is DLL sideloading the same as DLL hijacking?
They are no longer separate techniques. Sideloading is one named mechanism inside T1574.001, alongside search order hijacking, redirection, phantom hijacking and substitution. The practical difference between them is what each leaves behind, not which category they belong to.
How is it different from DLL injection?
Injection forces code into a process that is already running. Sideloading gets the process to load the code itself, as part of starting normally. Injection is a separate technique with its own entry and is out of scope here.
Do my existing detections still work?
Yes, if they were written against behaviour. A rule matching a module load from an unexpected path, or a file creation followed by a load of the same name, is unaffected. What needs updating is the ATT&CK identifier attached to it.
Which single log source shows it best?
Module load, Sysmon event 7. But the strategy is explicitly a correlation, so a module load on its own will generate more questions than answers without the file creation and process context beside it.
What to go check
The mechanism you already knew is still correct. The reference attached to it is not.
Two checks, and the second is the harder one.
- Grep for the retired identifier. Search the rule set, the coverage matrix, the report templates and any threat model for `T1574.002`, and repoint what turns up at T1574.001. While you are there, the tactic label on those same artifacts probably says Defense Evasion.
- Check whether the four baselines exist. Known-safe DLL directories, an allowlist of applications that legitimately load from unusual paths, a correlation window, and hashes for the legitimate DLLs. Most environments have telemetry and no baselines, which is why this technique tends to be detectable in theory and unalerted in practice.
The first check takes an afternoon. The second is what decides whether you would actually see it.