Your SIEM Is Watching the Wrong Event. DLL Hijacking Proves It.

Why a technique older than most defenders' careers still defeats modern detection stacks.

Most security teams spend their energy chasing the next big thing zero-days, ransomware variants, AI-driven malware.

Meanwhile, some attackers are still winning with techniques that have existed for decades.

One of them is DLL hijacking. Not because it's sophisticated. Because it's quietly ignored.

That should concern every defender reading this.

It's Not a Vulnerability. It's Abused Normal Behavior.

DLL hijacking doesn't exploit a flaw in Windows.

It exploits how Windows is designed to work.

When an application loads a DLL without specifying its full path, Windows searches for it using a predefined search order. If a malicious DLL with the same name exists in a higher-priority location Windows loads it. No crash. No warning. No exploit required.

This is expected behavior. And that's exactly why it's dangerous.

Defenders are trained to look for things that break. DLL hijacking doesn't break anything. It blends in.

Why This Technique Refuses to Die

If DLL hijacking is decades old, why do APT groups still rely on it in 2025 active campaigns?

Three reasons.

Reason 1: User-writable paths are everywhere.

Directories like C:\Users\Public\, AppData\Local, and misconfigured application folders are writable by standard users. No admin privileges needed. No UAC prompt. If a trusted executable loads a DLL from one of these locations, defenders often assume it's legitimate because the process is legitimate. The path is the lie, not the process name.

Reason 2: Missing DLLs create silent opportunity.

Many applications attempt to load DLLs that don't exist, were removed during updates, or were never shipped at all. Windows keeps searching until it finds something. If an attacker supplies a DLL with the expected name in a writable path, the system treats it as if it belongs there. Nothing looks broken. Nothing alerts. The application runs normally.

Reason 3: Phantom DLLs exploit the baseline problem.

Some applications try to load DLLs that were never supposed to exist legacy code, unused features, hardcoded imports from old builds. Defenders rarely baseline for something that "was never supposed to be there." Attackers exploit that silence. There's no alert for a DLL that was never in your inventory, because it was never in your inventory.

How Attackers Think About This

Attackers don't start by writing malware. They start by asking questions:

• Which signed binaries load DLLs without specifying full paths?

• Which directories can a low-privileged user write to?

• Which DLL name would look completely unremarkable in a log?

That's the entire methodology. No exploit development. No zero-day budget. Just a signed process, a writable directory, and a filename that looks like it belongs.

From a MITRE ATT&CK perspective this maps to T1574.001 (DLL Search Order Hijacking) and T1574.002 (DLL Side-Loading). Not exotic techniques. Techniques that have been in the framework since its early versions because they keep appearing in real incident data.

Where the Detection Signal Actually Lives

DLL hijacking is not invisible. It's just rarely monitored in the right place.

Here's what defenders should be watching and most aren't:

Signal 1: DLLs loaded from unusual paths. A signed, trusted binary loading a DLL from a user directory, temp folder, or non-standard location should always raise a question. Legitimate software rarely depends on DLLs stored in user-controlled paths. When it does, you should know exactly why.

Signal 2: Unsigned DLL loaded by a signed process. This is one of the strongest signals available. If a trusted executable loads an unsigned DLL or one signed by an unknown vendor outside of standard installation directories, that deserves immediate attention. The process being signed doesn't make the DLL safe.

Signal 3: Rare or first-seen DLL names. DLL hijacking relies on generic-sounding names and files that execute once and disappear. Frequency analysis matters more than signatures here. A DLL that appears in one log entry and never again is more interesting than one that appears a thousand times.

Signal 4: EventID 7, not just EventID 1. Most SIEM rules are built around process creation EventID 1. That's the wrong event for catching DLL hijacking. The attack lives in EventID 7 (image loaded), EventID 11 (file creation in writable paths), and the correlation between them. If your detection logic stops at process execution, you're monitoring the echo, not the event.

The questions that matter:

• Where was this DLL loaded from?

• Has this DLL name appeared in logs before?

• Does this path make sense for this process?

Ask those three questions consistently, and your Windows telemetry will look very different.

The Blind Spot Most SOCs Don't Notice

Here's the uncomfortable truth about most detection stacks:

SOCs monitor what executed. Attackers win in what was loaded.

DLL hijacking lives entirely in that gap. If your detection strategy doesn't baseline DLL load paths, flag user-writable DLL locations, and correlate signed processes with unsigned modules this technique bypasses your defenses without triggering a single alert.

Not because it's advanced. Because no one is looking in the right place.

What's Coming Next

This article is the concept. Part 2 is the proof.

I analyzed 37 real Sysmon events from an actual DLL hijacking attack using the hijacklibs dataset. Every signal I've described here appears in that log event by event, indicator by indicator. Non-admin execution, timestomping, masqueraded DLL names, sub-second process lifetime.

Part 2 shows exactly what this looks like in your SIEM before you build the detection logic.

Subscribe to follow the series. No filler posts each one builds directly on the last.

Manish Rawat is a detection engineer focused on the gap between what SIEMs cover and what attackers actually do.

Github: github.com/Manishrawat21

LinkedIN: linkedin.com/in/manishr…