Lion Cipher Lab
Detect DLL side-loading at fleet scale from Sysmon image-load events (Event ID 7)
- SOC Analyst / Blue Team
- Advanced
- ~90 min
- Free · no account required
Why it matters
DLL side-loading is one of the most reliable ways an intruder gets code to run inside a process your tools trust. They copy a legitimate, signed program into a folder they control, drop a malicious DLL next to it with a name that program asks for, and run the program. Windows looks in the program's own folder before System32, so the trusted program loads the attacker's code, and your process list shows only a signed binary from a known vendor. The telemetry that sees this is Sysmon's image-load event, and it is famous for two things: it is disabled by default because it is enormously noisy,…
What you'll learn
- Reading Sysmon Event ID 7 (ImageLoad) records: Image, ImageLoaded, Signed, Signature, SignatureStatus, Hashes
- Explaining DLL side-loading from the Windows DLL search order, including why KnownDLLs cannot be side-loaded
- Measuring what a Sysmon ImageLoad filter costs in volume and what it blinds you to
- Using fleet prevalence (how many hosts carry a hash, a pairing) as a detection signal
- Telling a staged software update apart from a single trojanised DLL with a folder-level drift check
- Explaining why a 'Signed = false' condition misses DLLs signed with stolen certificates
Steps in this lab
- What side-loading is, in one paragraph (and the ATT&CK ID that changed)
- Why Windows loads the attacker's copy: the search order and KnownDLLs
- The telemetry: Sysmon Event ID 7, and why it is off by default
- Build the synthetic fleet (1,984 image loads, 5 side-loads)
- Measure the collection first: what a Sysmon ImageLoad filter keeps and hides
- Write six rules and score them
- Read the progression: what each signal bought and what it cost
- Why 'Signed = true' is a weak reason to trust a DLL
- Honest limits: where the layered rule breaks
- Turn it into production work