Log Dejargonizer

Sysmon · Event 7

Sysmon Event 7: A module was loaded into a process

A process loaded a DLL or other module. Unfiltered it is the highest-volume event Sysmon produces, but filtered to unsigned modules loading from user-writable directories it catches DLL sideloading, which is otherwise very hard to see.

Also written as Sysmon 7Sysmon Event ID 7Image loadedSysmon DLL loaded

What it means for you

On a personal computer

Only present if you installed Sysmon. Every program loads dozens of these components; it is entirely normal.

For an analyst

Disabled by default in most configurations because of the volume, and rightly so. When you do enable it, filter to unsigned modules, to loads from user-writable paths, and to specific high-risk modules. Signature verification adds measurable overhead, and Sysmon caches results, so a module's signature status can be stale.

What it looks like

Sanitised. Addresses come from the RFC 5737 documentation ranges.

Sample
Image loaded:
  RuleName: -
  UtcTime: 2026-08-28 09:14:03.221
  ProcessGuid: {a1b2c3d4-0000-0000-0000-00000000abcd}
  ProcessId: 7412
  Image: C:\Users\jbrooks\AppData\Local\Temp\sigverif.exe
  ImageLoaded: C:\Users\jbrooks\AppData\Local\Temp\version.dll
  FileVersion: -
  Description: -
  Product: -
  Company: -
  OriginalFileName: -
  Hashes: SHA256=0000000000000000000000000000000000000000000000000000000000000000
  Signed: false
  Signature: -
  SignatureStatus: Unavailable
  User: CORP\jbrooks

The fields that decide it

Everything else in the log line is context.

ImageLoaded
The module that was loaded. The path matters more than the name.
  • A DLL in the same folder as a signed executable, outside Program FilesThe sideloading pattern — a legitimate signed program loading an attacker's DLL from beside it.
  • A DLL in a temp or user profile directoryModules rarely live here legitimately.
Image
The process that loaded it. A signed Microsoft binary loading an unsigned DLL from a user directory is the combination to watch.
Signed
Whether the module carries a valid signature.
  • falseUnsigned. Common for legitimate in-house software, so this needs environment-specific tuning.
Signature
The signer name, when signed.
SignatureStatus
Whether the signature actually validated. Valid is the expected value; anything else is worth reading.
OriginalFileName
The name the module was compiled with, which does not change when the file is renamed.

Ordinary reasons this happens

Most of the time it is one of these.

  • Every program loading its own libraries and the Windows components it depends on — nearly all of the volume.
  • In-house or niche software that is unsigned, which produces a persistent baseline of unsigned loads.
  • Development and build tools loading modules from working directories.
  • Plugins and add-ons loading into host applications.
  • Software mid-update loading a mix of old and new modules.

When it is not ordinary

DLL sideloading using a legitimate signed program.

What gives it awayA signed executable in a non-standard directory loading an unsigned DLL from beside it. The executable is genuine; the DLL is not.

ATT&CK T1574.002

A malicious module loaded into a trusted process.

What gives it awayAn unsigned DLL loading into a Windows system binary from a user-writable path.

ATT&CK T1055.001

Search order hijacking.

What gives it awayA module loading from a directory earlier in the search path than the legitimate copy.

ATT&CK T1574.001

A security product's module replaced or shadowed.

What gives it awayAn unexpected module loading into a security process, or a signature status other than valid on one of its components.

ATT&CK T1562.001

What to do next

  1. Check the signature status before anything else, then the load path.
  2. For a suspected sideload, look at whether the loading executable sits outside its normal install location.
  3. Compare ImageLoaded against OriginalFileName to catch a renamed module.
  4. Join on ProcessGuid to see the loading process's command line and parent.
  5. Check how widely the same module appears — in-house software will be on many machines.
  6. Check Sysmon Event 11 for when and by what the module was written to disk.

Queries to run

kql Unsigned modules loading from user-writable directories. Tune out your own in-house software first.
Event | where Source == 'Microsoft-Windows-Sysmon' and EventID == 7 | where Signed == 'false' and ImageLoaded has_any ('\\Users\\','\\Temp\\','\\AppData\\') | project TimeGenerated, Computer, Image, ImageLoaded
kql Signed Microsoft binaries running from user directories — the shape of a sideloading setup.
Event | where Source == 'Microsoft-Windows-Sysmon' and EventID == 7 | where Image startswith 'C:\\Users' and Signature has 'Microsoft' | project TimeGenerated, Computer, Image, ImageLoaded, Signature
splunk Unsigned modules on very few machines. Your own software is everywhere; this is the tail.
index=sysmon EventCode=7 Signed=false | stats count dc(host) as hosts by ImageLoaded | where hosts < 3 | sort -count

Common questions

Why is Sysmon Event 7 disabled in most configurations?

Because it fires for every module every process loads, which on a normal machine is tens of thousands of events per hour. It also requires signature verification, which adds measurable overhead. Enable it filtered to unsigned modules and user-writable paths rather than collecting it wholesale.

How do I detect DLL sideloading with Sysmon?

Look for a signed executable running from an unusual location loading an unsigned DLL from the same directory. Sideloading works by placing a legitimate signed program next to a malicious library it will load, so the executable looks clean and the directory is the giveaway.

Why does Sysmon sometimes report the wrong signature status?

Sysmon caches signature verification results for performance, so a status can be stale if a file changed after it was first checked. Treat signature status as a strong hint rather than proof, and verify the file directly when the answer matters.

Read next

Vendor documentation

Last reviewed 28 August 2026