What Is DLL Injection? How It Works and How to Detect It

DLL injection is a technique in which code from a dynamic link library (DLL) is loaded and run inside the address space of another, already-running process. This explainer is deliberately defensive: it describes what the technique is, why attackers value it, how it is detected, and how to shut down the conditions it depends on — without providing a weaponizable recipe.

First, what a DLL is

A dynamic link library is a shared library of code and data that Windows programs load at runtime rather than compiling into every executable. DLLs are everywhere and entirely normal: they let multiple programs share common functionality, keep executables small, and allow components to be updated independently. A running application typically has many DLLs loaded into its memory at once. Some legitimate software even loads libraries into other processes on purpose — debuggers, performance instrumentation, accessibility tools and compatibility shims all do this. The mechanism itself is a feature, not a flaw.

Why attackers abuse it

Attackers abuse DLL injection because running inside a trusted process buys them two prizes:

• Evasion. Code executing inside a signed, reputable process — a browser, an office application, a system service — inherits that process's identity, network reputation and permissions. Controls that make decisions based on the process name or signature see the trusted host, not the hostile code riding inside it. There is no obviously malicious standalone process for an analyst to spot.
• Persistence and stealth. Living inside a legitimate process helps an attacker maintain a foothold that survives casual inspection, and can let them observe or tamper with the data that process handles. The hostile activity is camouflaged by the host's normal behaviour.

In short, injection is attractive precisely because it borrows the trust that defenders and the operating system place in an existing process.

How it works, at a conceptual level

At a conceptual level, injection means causing a target process to load an attacker-chosen library and begin executing its code inside that process. Two things have to happen: the target must come to load the library, and execution must start within the target's context. Across the documented techniques that security researchers and defenders study, achieving this generally requires the attacker to already hold enough access to manipulate the target process — which is itself a useful fact for defenders, because it means injection is usually a later stage of an intrusion, not the entry point.

There are several well-known categories of mechanism, differing in how the load and the execution are triggered, and they are well-catalogued in defensive knowledge bases such as the MITRE ATT&CK process-injection techniques. This article intentionally stops at that level of description. Reproducing a working method adds nothing to a defender's ability to detect or prevent the technique, and the detectable behaviours below are the same regardless of which specific mechanism an attacker chooses.

How to detect DLL injection

The good news for defenders is that injection is noisy if you are watching the right events. It leaves observable traces, and modern tooling is built to catch them:

• Image-load (module-load) monitoring. The operating system and EDR can record every library a process loads. A process loading an unsigned, unexpected, or unusually located library — an office document handler suddenly loading an unknown DLL from a temporary folder — is a strong signal.
• Cross-process and memory behaviour. Injection depends on operations that touch another process's memory and execution. EDR can flag the suspicious memory allocations, cross-process access and remote thread creation these techniques require.
• Behavioural correlation. The highest-fidelity detections combine signals: a trusted process that loads an unexpected library and then makes anomalous network connections or spawns unusual children is far more suspicious than any one event alone.

Underpinning all of this is good telemetry. If module-load events and cross-process operations are not logged, injection becomes invisible — so the first defensive investment is ensuring the endpoint and EDR actually capture these events for hunting and alerting.

How to defend against it

Defence is layered, because the aim is to remove the conditions injection relies on and make any attempt loud:

• Code signing and loading policies. Configure processes and the platform to refuse unsigned or untrusted libraries, so an arbitrary attacker library cannot simply be loaded.
• Application control and allow-listing. Permit only approved code to run, shrinking the set of libraries that can ever be loaded.
• Least privilege. Because injection generally needs enough access to manipulate a target process, running users and services with minimal privilege reduces the number of viable targets and the blast radius if one is hit.
• Patch and harden. Keep systems updated to close the vulnerabilities attackers exploit to gain the access injection requires in the first place.
• EDR with behavioural detection. Deploy endpoint detection that watches image loads and the cross-process behaviours above, and alert on them.

Thinking through which processes an attacker would target, and what access they would need, is exactly the kind of reasoning a structured threat model formalises. Injection is one technique among many in the wider landscape of how intrusions actually unfold; our explainers on what an exploit is and what an attack vector is put it in context.

The takeaway

DLL injection abuses a legitimate operating-system capability to run attacker code inside a trusted process, buying evasion and persistence. It is not magic and it is not invisible: it generally requires access the attacker already won, and it leaves detectable traces in image-load and cross-process events. Defenders beat it by logging those events, enforcing signing and application control, applying least privilege, patching, and alerting on the behaviours injection cannot avoid. Understand the technique to recognise and dismantle it — that is the whole point of studying it.

Frequently asked questions

What is DLL injection? A technique that loads and runs code from a dynamic link library inside another, already-running process. The underlying capability is legitimate and widely used; the term usually refers to its malicious abuse.

Why do attackers use it? For evasion and persistence — code inside a trusted process inherits its identity, reputation and permissions, blending in and avoiding controls that key off the process name.

How does it work conceptually? By causing a target process to load an attacker-chosen library and execute its code; it generally requires access the attacker already holds, so it is usually a later intrusion stage, not the entry point.

How is it detected? Through image-load (module-load) monitoring, watching cross-process memory operations and remote thread creation, and correlating behaviours — all dependent on good endpoint telemetry and EDR.

How do you defend against it? Enforce code signing and loading policies, use application control and allow-listing, apply least privilege, patch systems, and deploy EDR that alerts on the behaviours injection requires.