Overview

DLL Side-Loading (T1574.002) is a technique where an attacker places a malicious DLL with a specific filename into a directory that a legitimate, often signed application will search before finding the real DLL. When the trusted application launches, it unwittingly loads the attacker’s code, executing the payload under the cover of a legitimate process identity. This gives attackers code execution, privilege escalation opportunities, and a stealthy foothold.

Because the malicious code runs inside a trusted, signed process — often security software, antivirus tools, or Microsoft applications — traditional allow-listing and signature-based controls frequently miss it. Every SOC needs reliable detection for this technique because it is a cornerstone of APT tradecraft, ransomware deployment, and long-term persistence campaigns, and its abuse of trusted processes means it actively undermines host-based defenses.

Attacker Perspective

Attackers exploit the Windows DLL search order to hijack legitimate application execution, turning trusted software into a malware launcher without touching the original binary.

• APT malware staging: Threat actors drop a malicious version.dll alongside a legitimate vlc.exe or winscp.exe in a user-writable directory; when the app launches, the malicious DLL initializes a Cobalt Strike beacon — a pattern well-documented in APT41 and Mustang Panda campaigns.
• Security tool abuse: Attackers copy a legitimate antivirus binary (e.g., MsMpEng.exe or components of Trend Micro, Symantec, or Kaspersky products) to an attacker-controlled folder and plant a malicious DLL matching a known side-loadable dependency — a technique used by PlugX and ShadowPad operators.
• LOLBin-adjacent abuse: Malicious dxgi.dll, wbemcomn.dll, or dbghelp.dll files are dropped alongside legitimate Windows utilities like msiexec.exe or wmic.exe to execute shellcode via a trusted Microsoft-signed parent process.
• Ransomware pre-staging: Ransomware groups (e.g., BlackCat/ALPHV) use side-loading to deploy encryptors — a malicious handler.dll is placed in the same directory as a copied legitimate binary and invoked via a scheduled task or service, bypassing application control policies.

DLL Side-Loading is attractive because it requires no kernel exploits, no code signing certificates, and no modification of protected system files — just file write access and knowledge of an application’s unguarded DLL dependencies.

Detection Strategy

Required Telemetry

• Windows Process Creation (Sysmon Event ID 1): Deploy Sysmon with a configuration that captures Image, ParentImage, CommandLine, CurrentDirectory, IntegrityLevel, Hashes, and User. Download the SwiftOnSecurity or Olaf Hartong Sysmon config as a baseline.
• Windows Image Load (Sysmon Event ID 7): This is the most critical log source for this technique. Enable it in your Sysmon config under ImageLoad with onmatch="exclude" for known-good paths. This event captures Image (the loading process), ImageLoaded (the DLL path), Signed, Signature, and SignatureStatus. Without this, DLL side-loading detection is largely blind.
• Windows File Creation (Sysmon Event ID 11): Captures new files written to disk including DLL drops. Fields include TargetFilename, Image (the process that wrote the file), and CreationUtcTime. Ensure the Sysmon config includes rules for .dll extensions in user-writable directories.
• Windows Security Audit — Process Creation (Event ID 4688): Enable via GPO: Computer Configuration → Windows Settings → Security Settings → Advanced Audit Policy → Detailed Tracking → Audit Process Creation = Success. Also enable command-line auditing via GPO: HKLM\SOFTWARE\Microsoft\Windows\CurrentVersion\Policies\System\Audit → ProcessCreationIncludeCmdLine_Enabled = 1. Captures New Process Name, Creator Process Name, and Process Command Line.
• Windows Security Audit — Object Access (Event ID 4663): Enable via GPO: Advanced Audit Policy → Object Access → Audit File System = Success, Failure. Required on sensitive directories to catch DLL writes. Place a SACL on high-risk directories (e.g., C:\ProgramData\, C:\Users\Public\).
• Windows Defender / MDE (Microsoft Defender for Endpoint): MDE natively captures image load events, file creation, and process injection telemetry. Use the DeviceImageLoadEvents, DeviceFileEvents, and DeviceProcessEvents tables in Advanced Hunting if available.
• EDR Telemetry (CrowdStrike, SentinelOne, Carbon Black): All major EDRs capture DLL load events. Ensure DLL load enrichment is enabled in your EDR policy — some vendors disable it by default due to volume. In CrowdStrike Falcon, ensure DLL Load events are included in your prevention policy telemetry settings.
• Network Flow / Proxy Logs: DNS query logs and proxy logs capture outbound connections initiated by processes. Correlate process image name with unexpected external connections — a security tool binary connecting to an unknown IP is a strong signal.

Key Indicators

• DLL loaded from non-standard path: In Sysmon Event ID 7, check ImageLoaded — any DLL with a name matching a known Windows system DLL (e.g., version.dll, wbemcomn.dll, dxgi.dll, dbghelp.dll) loaded from a path outside C:\Windows\System32\ or C:\Windows\SysWOW64\ is suspicious. Example: ImageLoaded = C:\Users\Public\Tools\version.dll.
• Unsigned or invalid-signature DLL loaded by signed process: In Sysmon Event ID 7, check Signed = false OR SignatureStatus != Valid where Image is a signed binary. Example: Image = C:\Program Files\VLC\vlc.exe AND Signed = false.
• Legitimate binary running from unusual directory: In Sysmon Event ID 1 or Event ID 4688, check Image path — well-known executables (e.g., MsMpEng.exe, winscp.exe, vlc.exe) running from C:\Users\, C:\ProgramData\, C:\Temp\, or C:\Windows\Temp\ rather than their expected install paths. Example: Image = C:\ProgramData\upd\MsMpEng.exe.
• DLL written to same directory as a known side-loadable binary: In Sysmon Event ID 11, check TargetFilename ending in .dll in directories that also contain security product binaries or legitimate applications copied out of their install paths.
• Unexpected parent-child process relationship: In Sysmon Event ID 1, check ParentImage — if a legitimate application binary that does not normally spawn children creates cmd.exe, powershell.exe, or a network tool, it may have been hijacked. Example: ParentImage = C:\ProgramData\upd\MsMpEng.exe AND Image = C:\Windows\System32\cmd.exe.
• Network connection from unexpected process: In Sysmon Event ID 3 (Network Connection), check Image against processes that have no legitimate reason to make outbound connections. Example: Image contains MsMpEng.exe AND DestinationPort = 443 AND DestinationIp is not a known Microsoft IP range.
• Hash mismatch on known binary name: In Sysmon Event ID 7 or EDR telemetry, check the SHA256 hash of a loaded DLL named version.dll or dbghelp.dll against known-good hashes from Microsoft’s symbol server or VirusTotal. A DLL named like a system DLL but with an unknown hash is high-confidence.

Detection Logic

Rule 1 (Broad — High Sensitivity): Known System DLL Loaded from Non-System Path
IF event_id = 7 (Sysmon ImageLoad)
AND ImageLoaded MATCHES ".*\\(version|wbemcomn|dxgi|dbghelp|cryptbase|cryptsp|wldap32|rasapi32|winhttp|wtsapi32|msvcp|vcruntime).*\.dll$" (case-insensitive)
AND ImageLoaded NOT STARTS_WITH "C:\Windows\System32\"
AND ImageLoaded NOT STARTS_WITH "C:\Windows\SysWOW64\"
AND ImageLoaded NOT STARTS_WITH "C:\Windows\WinSxS\"
THEN alert HIGH

This catches the core mechanic: a DLL with the same name as a known Windows library loaded from an attacker-controlled directory. Expect moderate to high volume initially — requires tuning against known-good application directories (e.g., legitimate applications that ship their own version.dll). Build a whitelist of approved paths over 1–2 weeks before promoting to high-priority alerting.

Rule 2 (Medium — Unsigned DLL Loaded by Signed Process):
IF event_id = 7 (Sysmon ImageLoad)
AND Signed = "false" (OR SignatureStatus != "Valid")
AND Image IS signed (Signed = "true" for the parent process, confirmed via Event ID 1 or EDR telemetry)
AND ImageLoaded NOT STARTS_WITH "C:\Windows\"
AND ImageLoaded NOT STARTS_WITH "C:\Program Files\"
AND ImageLoaded NOT STARTS_WITH "C:\Program Files (x86)\"
THEN alert HIGH

A signed, reputable binary loading an unsigned DLL from a non-standard path is a strong signal with lower false-positive rate than Rule 1. This catches attackers who don’t bother signing their payload DLL. Alert volume should be low after baseline tuning.

Rule 3 (Narrow — Legitimate Security Tool Binary Executing from Anomalous Path):
IF event_id = 1 (Sysmon ProcessCreate)
AND Image MATCHES ".*(MsMpEng|msmpeng|MBAMService|avgnt|egui|NTRTScan|ccSvcHst|bdservicehost).*\.exe$" (case-insensitive)
AND Image NOT STARTS_WITH "C:\Program Files\"
AND Image NOT STARTS_WITH "C:\Program Files (x86)\"
AND Image NOT STARTS_WITH "C:\ProgramData\Microsoft\Windows Defender\"
THEN alert CRITICAL

Security product binaries running from user-writable directories are almost never legitimate and almost always indicate side-loading setup. This is a precision rule — expected volume is very low (near zero), and any hit should be treated as a confirmed incident pending investigation.

Rule 4 (Correlated — Suspicious Process Spawned by Side-Loaded Binary):
IF event_id = 1 (Sysmon ProcessCreate)
AND ParentImage IS NOT IN known_legitimate_parent_list
AND ParentImage runs from path MATCHING "(C:\Users\|C:\ProgramData\|C:\Temp\|C:\Windows\Temp\)"
AND Image MATCHES ".*(cmd\.exe|powershell\.exe|wscript\.exe|mshta\.exe|regsvr32\.exe|rundll32\.exe|certutil\.exe)$"
THEN alert CRITICAL

This catches the downstream execution: once the side-loaded DLL initializes, it frequently spawns a command interpreter or LOLBin to execute further stages. High confidence, low volume. Correlate with Rule 1 or Rule 2 events on the same host within a 10-minute window for maximum fidelity.

Tuning Guidance

• Legitimate applications shipping their own DLL copies: Many software vendors (particularly older or poorly packaged applications) bundle their own copies of system DLLs like version.dll or msvcp140.dll in their install directory. Whitelist by adding exclusions for ImageLoaded STARTS_WITH "C:\Program Files\[VendorName]\" after validating the vendor’s DLL is signed and the hash is known-good.
• Development and build tools: Visual Studio, Python environments, and Java runtimes frequently load DLLs from non-standard paths during compilation or runtime. Exclude by Image STARTS_WITH "C:\Program Files\Microsoft Visual Studio\" or Image STARTS_WITH "C:\Python\" and scope exclusions to known developer workstation OUs in Active Directory — never apply these exclusions globally to servers.
• Portable applications: Tools like SysInternals utilities, portable browsers, or portable security tools run from C:\Users\ subdirectories and may load DLLs locally. Identify these through a baselining period: collect 2 weeks of Rule 1 alerts, group by Image and ImageLoaded, review unique combinations, and add approved entries to an exclusion list. Require security team sign-off before adding any exclusion for a user-writable path.
• Software deployment tools (SCCM, Intune, PDQ): Deployment agents may temporarily place binaries and DLLs in staging directories before moving them to final locations. Exclude the deployment agent process: ParentImage IN (ccmexec.exe, PDQDeployRunner.exe) during known deployment windows, or scope exclusions to the specific staging paths used by your deployment tooling.

When the Alert Fires: Investigation Steps

1. Verify the alert is real: Pull the raw Sysmon Event ID 7 or EDR image load event from your SIEM and confirm all key fields — Image, ImageLoaded, Signed, SignatureStatus, and timestamp — are present and consistent with the alert logic. Cross-reference the event against the originating host’s Sysmon or EDR agent health to rule out logging artifacts or data parsing errors.
2. Identify the affected host and user: From the process creation event (Sysmon Event ID 1 or Event ID 4688), extract Computer (hostname), User, and IntegrityLevel — escalated integrity level (High or System) significantly increases severity. Check the user account against your privileged account list and Active Directory groups; if the account has admin rights or is a service account, escalate priority immediately.
3. Pull the full process tree: In your SIEM or EDR console, reconstruct the full parent-child chain starting from the process that loaded the suspicious DLL — use Sysmon Event ID 1 fields ProcessGuid and ParentProcessGuid to walk the tree. Document every process in the chain including command-line arguments, working directory, and file hashes; this establishes whether a human or automated task triggered the chain.
4. Examine the DLL on disk: Use your EDR’s file retrieval capability or a live response tool (e.g., CrowdStrike RTR, Microsoft Live Response, Velociraptor) to collect the suspicious DLL from the affected host. Submit the SHA256 hash to VirusTotal and your internal threat intel platform, and check the DLL’s PE headers (compile timestamp, imports, exports, embedded strings) using a tool like PEStudio or FLOSS to identify C2 configuration or shellcode loaders.
5. Check for network connections: Search Sysmon Event ID 3 or EDR network telemetry for outbound connections made by the loading process or its children within 30 minutes of the DLL load event. Extract all destination IPs and domains, check them against threat intel feeds (VirusTotal, Shodan, your TIP), and review proxy/DNS logs for any successful data transfers — look for beaconing patterns (regular intervals, consistent byte counts).
6. Search for lateral movement and persistence: On the affected host, query Sysmon Event ID 13 (Registry value set) for new Run keys, services (HKLM\SYSTEM\CurrentControlSet\Services), and scheduled tasks (Sysmon Event ID 11 for new .job files or Windows Event ID 4698 for scheduled task creation). Pivot to your SIEM’s authentication logs (Event ID 4624, 4648) to identify any outbound authentications from the host to other internal systems in the hours following the DLL load.
7. Make the escalation decision: Confirmed incident indicators include: the DLL hash is flagged malicious in threat intel, the process tree shows execution of known offensive tooling (Cobalt Strike, Meterpreter beacons), outbound C2 connections are confirmed, or evidence of credential access or lateral movement exists — escalate to IR immediately and isolate the host. If the DLL is unsigned but unknown, process tree is benign, and no network activity is observed, treat as suspicious and continue investigation under a lower-priority IR ticket while preserving forensic artifacts.

Response Playbook

Containment

• Isolate the host — keep it powered on: Use your EDR console (CrowdStrike Network Containment, SentinelOne Network Quarantine, MDE Isolate Device) to sever the host’s network access while keeping it running. Do not power it off — volatile memory may contain decrypted payloads, active C2 configuration, or process artifacts needed for forensics.
• Disable the affected user account: In Active Directory, use Disable-ADAccount -Identity [username] or the ADUC console to immediately disable the account. If the account is a service account, coordinate with the application owner before disabling — identify an alternative service account or application downtime window if required.
• Block identified C2 indicators at the network perimeter: Submit all malicious IPs, domains, and URLs identified in step 4 and 5 to your firewall team and DNS security platform (e.g., Cisco Umbrella, Palo Alto DNS Security, Infoblox) for immediate block. Also push the indicators to your web proxy deny list. Document every indicator blocked with timestamp for the incident record.
• Kill the malicious process: Using your EDR’s live response capability, terminate the process hosting the malicious DLL by PID. In CrowdStrike RTR: kill [PID]. In Microsoft Live Response: remediate-process -pid [PID]. If EDR live response is unavailable, use a remote PowerShell session: Stop-Process -Id [PID] -Force — but note this should only be done after memory acquisition if feasible.
• Revoke active sessions and tokens: In Azure AD / Entra ID, run Revoke-AzureADUserAllRefreshToken -ObjectId [UPN] or use the “Revoke Sessions” button in the Entra ID portal to invalidate all active tokens for the affected user. For on-premise environments, reset the user’s Kerberos TGT by resetting their password and running klist purge on any known sessions.

Eradication

• Remove the malicious DLL and associated files: Using EDR live response or Velociraptor, delete the malicious DLL from disk. Search the entire host for additional copies using the file hash: in CrowdStrike RTR use filehash search; in Velociraptor use glob with the known filename. Also search the host for any additional dropped payloads (shellcode files, config files, additional executables) in C:\Users\, C:\ProgramData\, C:\Temp\, and C:\Windows\Temp\.
• Remove identified persistence mechanisms: Delete any malicious scheduled tasks identified in investigation step 6 using schtasks /delete /tn "[TaskName]" /f via live response. Remove any malicious registry Run keys using reg delete "HKCU\Software\Microsoft\Windows\CurrentVersion\Run" /v [ValueName] /f. For malicious services, use sc delete [ServiceName] after stopping the service.
• Reset credentials for all involved accounts: Reset passwords for the affected user account and any service accounts the malicious process ran under. If the process had access to credential stores, LSASS memory, or a secrets manager, assume those credentials are compromised and rotate them — coordinate with the relevant application and infrastructure owners.
• Hunt for lateral movement targets: Using the authentication log pivot from investigation step 6, identify every host the compromised account authenticated to after the DLL load. Run the same DLL side-loading detection queries against those hosts in your SIEM. Deploy additional EDR scanning to those hosts and check for the same DLL hash, filename, and persistence mechanisms.
• Rotate exposed secrets: If the compromised host had access to API keys, certificates, database credentials, or cloud IAM credentials (e.g., AWS instance profile, Azure managed identity), rotate those immediately. Check your secrets management platform (HashiCorp Vault, AWS Secrets Manager, Azure Key Vault) for access logs from the time of compromise and identify what was accessed.

Recovery

• Verify cleanliness before reconnecting: Before lifting network isolation, run a full EDR scan and verify no malicious files, persistence mechanisms, or suspicious processes remain. If confidence in cleanliness is less than high — particularly if the host was compromised for an extended period or if the attacker had SYSTEM-level access — re-image the host from a known-good golden image rather than attempting cleanup in place.
• Re-enable the user account only after confirming no persistence remains: Before re-enabling the account in Active Directory, confirm with the investigating analyst that no persistence tied to this account exists on any host. Reset the password to a new strong credential, enforce MFA if not already required, and notify the user of the incident and the new credentials through an out-of-band channel.
• Monitor the affected host and user for 72 hours post-remediation: Create a temporary high-sensitivity watchlist in your SIEM for the affected hostname and user account. Set alerts for any DLL load from a non-standard path, any new process spawning from unexpected parents, and any outbound connection to new external destinations. Review these alerts manually every shift for the 72-hour window.
• Document the full timeline and conduct lessons learned: Create a detailed incident timeline from first artifact to containment in your ticketing system (ServiceNow, Jira, etc.), recording every IOC, every action taken, and timestamps. Within 5 business days, hold a lessons-learned meeting with the SOC team to review detection gaps, response delays, and whether the existing Sysmon and EDR configuration would have caught earlier stages of the attack.
• Update detection rules with new IOCs: Add any new DLL filenames, hashes, parent-child process pairs, and C2 indicators discovered during the investigation to your SIEM detection rules and threat intel platform. If the attacker used a previously unknown side-loadable binary pair, add a specific detection rule for that combination and share the IOCs with your ISAC or threat intelligence sharing community.