DLL Sideloading (T1574.001)

DLL sideloading is a Windows technique in which an attacker places a malicious DLL (a library file of program code) beside a legitimate program that can be made to load it, at startup or later. The attacker's code then runs inside a trusted program, which can make the activity look ordinary.

Explain It Like I'm 10

Picture a teacher who tells the class to hand in "the fractions worksheet". Each kid looks in their own bag first, then in the teacher's tray, and hands in the first sheet with that title. Someone slips a fake worksheet with the same title into a kid's bag. The kid hands it in, sure it is the right one.

Windows programs can be fooled in roughly the same way: they ask for a file by name, look close to home first, and use the first match. The kid did nothing wrong. The fake sheet was just in the first place they looked.

What is a DLL, and why do programs load them?

A DLL, short for dynamic-link library, is a file of shared program code. Microsoft defines it as a module that contains functions and data that another program can use. Instead of every program carrying its own copy of the same code, programs call on DLLs, which makes the functionality easier to update and reuse. Programs that use the same functionality at the same time also share the DLL's code.

DLLs are ordinary and useful. MITRE's ATT&CK knowledge base of adversary tactics and techniques says DLLs are not malicious by nature. They can, however, be abused, and sideloading is one way.

How does Windows decide which DLL to load?

A program usually asks for a DLL by name. Microsoft notes that a program can fix the exact location by giving a full path. When it does not, Windows searches for the DLL when the DLL is loaded. The part of Windows that does this is the DLL loader. A program can load a DLL when it starts or later, while it is already running.

For an ordinary desktop program with Windows' default settings, the search first checks a few special cases: a DLL with the same name that is already loaded, a DLL that has been redirected for the program, and a short list of system DLLs called known DLLs. For a known DLL, Windows uses its own copy. After those cases, Windows checks folders in this order (trimmed to the ones that matter here):

• the folder containing the program's executable (the file that runs the program), called here the program's own folder;
• the system folder;
• the Windows folder;
• the current folder: the process's current (working) directory, which can differ from the executable's folder and is not simply wherever the user is working (a default setting called safe DLL search mode keeps this one late in the list).

A search like this works from the top: the first match is the one used. Two things follow. The program's own folder is checked before the system folders, so a file placed there can be found first. And the special cases come before any folder, so the technique depends on which DLL a program asks for: for a known DLL, Windows has already settled which copy to use.

How does an attacker's file end up being loaded?

The opening is Windows' rule about where to look. Microsoft states the condition: if an attacker gains control of one of the directories that is searched, they can place a malicious copy of the DLL there. In sideloading the planted file sits beside the program, in the program's own folder, which the search checks before the system folders. When the program next asks for that DLL by name, the search finds the planted copy and loads it. The copy then runs inside the program's process, the running instance of the program, and acts with whatever rights that process has.

MITRE's definition of sideloading adds what makes it sideloading. The attacker plants the file and then invokes a legitimate application, so that the application runs the attacker's code. Side-loading puts the application and the malicious file alongside each other.

What the application has to allow

Sideloading needs a legitimate application whose DLL-loading behavior lets the planted library be selected and loaded. An executable alone does not guarantee that: a program that loads a library by full path, or asks for a known DLL, gives a planted copy of that library no way in.

Two situations

Security vendor Bitdefender separates two situations. In the first, the attacker brings a trusted program onto a machine and puts the malicious DLL next to it. Because the attacker supplies both, the attacker chooses the folder; whether the planted file then gets loaded still depends on how the application loads that DLL. In the second, the attacker targets an installed program that is vulnerable to loading a library from an unsafe location. That also needs a way to put a file in a location the program searches, which is the condition Microsoft describes above.

What does a real campaign look like?

In a report published on 11 August 2026, Check Point Research described a long-running campaign it calls Operation Dream Job, which it links to the Lazarus group and which targets organizations worldwide, with a focus on the defense sector. In one infection chain it describes, the victim is persuaded to download an encrypted archive of three files: a genuine PDF viewer, a malicious DLL, and an encrypted file of the attacker's code with a PDF extension.

The chain is short. The victim launches the genuine viewer. The viewer loads the malicious DLL through sideloading; the DLL came in the same archive as the viewer. The DLL then shows a decoy PDF to the victim while it decrypts and runs the hidden code in memory. The victim sees an ordinary document, and a genuine program has done the loading.

This is one documented campaign, not a measure of how common the technique is. The report says the exact way victims were first approached remains unclear.

Why does running inside a trusted program matter?

Three things make a trusted program a useful cover:

• It masks the activity: MITRE says attackers likely use sideloading to mask what they do under a legitimate, trusted and potentially elevated process, meaning a running program that may hold extra rights, and that the benign programs used this way may not be flagged during delivery or execution. A hijacked program may also appear to behave normally. A check that stops at whether the program is genuine may find nothing wrong, because the program is.
• It inherits the host process's rights: The loaded DLL runs inside the host process, the program that loaded it, so the code can operate with that process's privileges. If the process runs with elevated privileges, the loaded code can too, and MITRE notes the technique could be used for privilege escalation, which means gaining higher-level permissions. Sideloading does not by itself grant administrator or SYSTEM access (SYSTEM is a built-in account with extensive privileges): the code starts with only the rights its host process has.
• It can repeat: Persistence, meaning keeping a foothold on a system, is another purpose MITRE lists for hijacking the way a system runs programs, since the hijacked execution may reoccur over time.

None of this makes DLLs, or the software that loads them, the problem. A program that asks for a library by name is doing what Windows documents.

How is DLL sideloading different from DLL hijacking and DLL injection?

MITRE ATT&CK lists DLL sideloading in one entry, T1574.001, "Hijack Execution Flow: DLL" (for Windows). MITRE describes sideloading as hijacking which DLL a program loads, so "hijacking" is the broader word for redirecting DLL loading, while "sideloading" stresses a legitimate application loading attacker-controlled code. A sideloading attack can exploit search order hijacking, so one attack can fit both names. The entry lists five related mechanisms that can overlap:

In all five, the program loads the attacker's file as a normal part of running. They differ in where the file sits and what the attacker changed to get it loaded.

DLL injection is a different technique, listed as T1055.001. It forces code into a process that is already running from outside: MITRE describes it as a method of executing arbitrary code in the address space of a separate live process. In sideloading, the program does the loading itself, as part of running.

What stops DLL sideloading, and where does each defense stop working?

Each defense works at a different point in the chain, and each has a boundary.

Programs that name where their libraries are

Microsoft's guidance for developers is to specify a full path when loading a library, or to set the search order for the process. A full path removes the search for that library, so there is nothing for a planted copy to win. The boundary is that it helps only programs whose authors do it, and Microsoft notes that a DLL's own dependencies (the other DLLs it needs) are still searched by name alone, even when the first DLL was loaded by full path. Windows' safe DLL search mode moves the current folder later, which Microsoft says increases the chances that Windows finds a legitimate copy before a malicious one. It increases the chances; it does not remove the program's own folder from the order.

Application control that checks libraries

A control that approves only the programs allowed to run judges the program, and in sideloading the program is genuine. MITRE's execution-prevention advice is therefore application control that can block DLLs loaded by legitimate software. In Microsoft's AppLocker, DLL rules make AppLocker check each DLL an app loads. The cost is that a DLL allow rule is needed for each DLL used by every allowed app, including Windows system files, and checking every DLL may slow resource-constrained computers.

Patching and auditing

MITRE recommends updating software regularly to include patches that fix DLL side-loading vulnerabilities, and using auditing tools that can find DLL search order hijacking opportunities in an enterprise so they can be corrected. Both work on software an organization already runs. Neither changes a program the attacker brings along, as in the campaign above.

Detection

MITRE's detection strategy correlates file system changes, registry changes and module-load telemetry, which are records of which DLL each program loaded, to spot abnormal DLL behavior in trusted processes. It is not a fixed rule. Applications such as development tools are expected to load DLLs from unusual places, so the strategy has to be tuned with known-safe folders, an allowlist of such applications, a correlation window (how close in time events must be to count together) and baseline hashes (fingerprints) of legitimate DLLs. Without that tuning, ordinary loads may look like abuse.

The thread through all four is the same. The attacker needs a legitimate program whose DLL-loading behavior lets a planted file be selected, and a place the program searches to put it. Each defense removes that place, judges the file that loads, or watches the load.