Windows Event ID 7 — Image Loaded

MITRE ATT&CK

Why It Matters

DLL-based attacks are popular precisely because they hide inside trusted processes: a signed, legitimate application loads an attacker-supplied DLL, and all subsequent malicious activity runs under the trusted process's identity. Process creation logging sees only the legitimate host process; Sysmon 7 exposes every DLL it loads. The Signed and SignatureStatus fields immediately flag unsigned or invalidly-signed DLLs loading into signed Microsoft processes — a high-confidence sideloading or injection indicator.

Key Fields

Normal vs Suspicious

Investigation Tips

1. 1.DLL sideloading signature: a signed Microsoft or vendor application loading an unsigned DLL from the same directory as the application, or from AppData/Temp. The canonical pattern: legitimate EXE in user-controlled path + unsigned DLL with a name matching a known system DLL = sideloading.
2. 2.Reflective DLL injection: Signed = false, ImageLoaded path contains memory artifacts (e.g. paths that don't exist on disk, very short paths), or CallTrace (if enabled) shows unusual memory regions. Sysmon 7 with ImageLoaded from a non-existent path indicates an in-memory injection.
3. 3.Watch for unsigned DLLs loading into high-value processes: lsass.exe, winlogon.exe, services.exe, explorer.exe — these processes are targeted for injection because they run with high privileges and are trusted by security products.
4. 4.Known DLL masquerade: compare ImageLoaded filename against the list of known Windows system DLLs (kernel32.dll, ntdll.dll, user32.dll). A DLL named kernel32.dll loading from C:\Users\Public\ is masquerading as a system DLL — attackers rely on DLL search order to make the fake load before the real one.
5. 5.Hash the ImageLoaded DLL and check VirusTotal — even without a signature mismatch, known malicious DLLs will be flagged. Submit both MD5 and SHA256 for broadest coverage.

How Attackers Evade This Event

• →Code signing abuse — attackers sign their malicious DLLs with stolen, purchased, or self-signed certificates; Signed = true but the signing identity is not a trusted vendor
• →Memory-only (reflective) DLL loading — DLL is loaded directly from memory and never written to disk; Sysmon 7 may still fire but ImageLoaded path will show a memory region or non-existent path
• →DLL proxying — malicious DLL exports all the same functions as the legitimate DLL it replaces and forwards calls to the real DLL; appears functional and may retain a valid signature if the PE metadata is carefully preserved
• →Load-time hijacking via DLL search order — placing a malicious DLL earlier in the Windows search path than the legitimate one; the legitimate application loads it automatically without any API injection needed
• →Legitimate certificate abuse — some attackers use expired or poorly-validated certificates that Sysmon marks as Expired rather than Invalid, which is lower priority in many detection rules

Related Event IDs

Frequently Asked Questions

Why does Sysmon Event 7 generate so many events and how do I filter it?

Every process loads dozens to hundreds of DLLs during startup — a browser can load 300+ DLLs in a single session. Unfiltered, Sysmon 7 is often the highest-volume Sysmon event. Practical filtering: (1) In your Sysmon config, include only events where Signed = false — this reduces volume by 90%+ while catching almost every attack. (2) Exclude DLL loads from System32 and SysWOW64 by trusted processes — these are almost always legitimate. (3) Focus collection on high-value target processes: lsass.exe, winlogon.exe, services.exe, and any process in your watchlist. The goal is unsigned DLLs in trusted processes and system DLL names from wrong paths — not every DLL load.

What is DLL sideloading and how is it different from DLL injection?

DLL sideloading exploits Windows DLL search order: when an application loads a DLL by name without a full path, Windows searches in a defined order (application directory first, then System32, etc.). Attackers place a malicious DLL with a system DLL's name in the application's directory, causing the application to load the malicious one instead. The legitimate application is unmodified — it just loads the wrong DLL. DLL injection, by contrast, forces an already-running process to load an attacker-supplied DLL into its memory space, typically via WriteProcessMemory + CreateRemoteThread or similar APIs. Sideloading appears in Sysmon 7 as an unsigned DLL with a system name loading from a wrong path; injection appears as unsigned DLL loading from memory or an unusual path into a running trusted process.

How do I use Sysmon Event 7 to detect LSASS credential dumping?

Credential dumping tools that inject into LSASS (rather than opening a handle to it) appear in Sysmon 7 as unsigned or unexpected DLLs loading into lsass.exe. Look for: ImageLoaded with Signed = false in the Image = lsass.exe context, DLLs loading from AppData or Temp into lsass.exe, or known credential dumping DLL hashes. However, the more reliable LSASS dump detection uses Sysmon Event 10 (Process Access) with GrantedAccess 0x1010 or 0x1410 — that catches handle-based dumping (ProcDump, Task Manager) which doesn't require DLL injection. Use Sysmon 7 for injection-based dumping and Sysmon 10 for handle-based dumping together.