A Non-Admin User Executed Malware in Under 1 Second. My SIEM Fired Zero Alerts. Here's the Full Log.

37 real Sysmon events. One complete DLL hijacking attack. This is what it actually looks like.

In my last post I made a claim. Most SIEMs are watching the wrong event. DLL hijacking lives in the gap between what executed and what was loaded. Claims are easy. Evidence is harder. So I went and found the evidence.

The Dataset

I ran the hijacklibs dataset through Splunk Enterprise, a publicly available malware sample capturing a complete DLL sideloading attack from initial execution to payload delivery. Real attack behavior. Real telemetry.

Total events analyzed: 37. Distinct event types: 6 (EventID 1, 2, 5, 7, 11, 26). Attack duration: under 1 second. User account: non-admin. UAC prompts triggered: zero. Admin privileges used: zero.

That last part is what matters. A standard unprivileged account. No exploits. No elevated access. Complete code execution. If that account existed in your environment right now, most default detection stacks would not have fired once.

The Attack, Event by Event

EventID 1 — Process Creation

pollev (1).exe launches from C:\Users\attacker\Downloads\ and the (1) in the filename is already the first tell. That suffix is what browsers add when you download the same file twice. Legitimate system software does not come from Downloads. Legitimate system software definitely does not come from Downloads twice. This is the event everyone monitors and yes, it looks suspicious here. But the attack has not happened yet. This is just the door opening.

EventID 11 — File Creation

Four DLL files appear in C:\Users\attacker\AppData\Local\Temp\nsp43C0.tmp\ and their names are System.dll, version.dll, UAC.dll and AccessControl.dll. Read those names again because they are legitimate Windows component names. Trusted names. Names that appear in normal process logs thousands of times a day across any environment. The attacker is not trying to hide anything. They are borrowing trust. When your log already has ten thousand references to version.dll from System32, one more version.dll from %TEMP% disappears completely into the noise. The location is the anomaly, not the name, and that distinction is exactly where most detection stacks go blind.

EventID 26 — Executable Identification

Sysmon flags all four DLLs with IsExecutable set to true. This event gets tuned out on most teams because it is noisy, but IsExecutable=true on files sitting in %TEMP% is not noise. It is confirmation that these are not passive data files. They contain code that is about to run.

EventID 7 — Image Load

pollev.exe loads the malicious DLLs from %TEMP% and this is where the hijacking completes. Windows searched for System.dll, found the attacker's version in %TEMP% before it reached System32, and loaded it without a single complaint. The process is signed. The DLL name is familiar. The load behavior looks completely normal. The only anomaly is the path and if nobody is correlating DLL load paths against the processes loading them, nothing fires. Under one second from EventID 1. Done.

EventID 2 — File Time Change

Immediately after execution the timestamps on the malicious DLLs are modified. This is T1070.006, timestomping, and it exists to erase the forensic timeline. If an investigator later asks when these DLLs appeared, the filesystem will give the wrong answer. The Sysmon log is the only accurate record left. The fact that the attacker does this at all tells you something important: they expected someone to look later. This is not sloppy work.

EventID 5 — Process Termination

pollev.exe exits immediately. No persistence mechanism. No C2 connection. No lingering. The dropper placed the payload and its job is finished. Staying alive any longer only increases detection risk, so it does not. Short-lived processes are a deliberate evasion choice because behavioral detection engines need dwell time to build a profile. A process that lives for under a second defeats them by design, not by accident.

The Five Indicators That Confirm This Attack

Looking across all 37 events, five things stand out as the clearest confirmation signals that something went wrong here.

The entire attack runs as a standard non-admin account with no privilege escalation at any point, which breaks the assumption that low-privilege users represent low risk. The executable launches from Downloads rather than Program Files or System32, which is never where legitimate installed software runs from. The malicious DLLs are written to %TEMP% which is writable by any user by design, and defenders often carve out exceptions for temp directory noise without realizing that exception is the attack surface. EventID 26 confirms IsExecutable=true on files that have no business being executable in that location, and when you correlate that against the process that created them the picture becomes unambiguous. Finally the DLL names are trusted Windows component names placed in an untrusted location, and any detection logic that checks the name without checking the path will miss this completely every single time.

The MITRE Mapping

Three techniques working together in one attack chain. DLL Side-Loading (T1574.002) is the core execution method. Masquerading (T1036.006) explains the legitimate names in illegitimate paths. Timestomping (T1070.006) explains EventID 2 erasing the forensic timeline after execution. None of these are obscure or new techniques. All three have been in ATT&CK for years. They appeared together here because they complement each other: masquerading gets the DLL loaded, timestomping removes the evidence, side-loading connects both to execution.

The Lesson

DLL hijacking succeeds because defenders focus on what executed rather than what was loaded. EventID 1 showed suspicious execution but EventID 11 confirmed the attack. EventID 7 is where the hijacking completed and most default SIEM rules do not touch it. The gap between process execution and DLL loading is where this attack lived from start to finish.

What Is Coming Next

The Sigma detection rules for everything shown in this post are coming Monday. That post is also where this series escalates significantly because Monday is not about DLL hijacking in a lab dataset. Monday is about APT29, the Russian SVR group running active campaigns right now in 2025, and how the same evasion logic you just watched play out across 37 events scales to nation-state operations targeting cloud infrastructure. Same framework. Considerably higher stakes.

Subscribe so you do not miss it. The detection rules will be worth the wait.

Open to Collaboration

Building detection rules that actually work in real environments is what drives me. The gap between theory and practice is huge, and that’s where the interesting problems are.

If you’re working on detection engineering, scaling your SOC, or trying to improve threat hunting in your environment, I’m interested in talking about it.

I’m open to remote contract work or project-based collaboration where I can contribute expertise in detection engineering. If your team is serious about improving threat detection capabilities and understanding real-world attack patterns, let’s connect.

LinkedIn: linkedin.com/in/rawat-m…

GitHub: