MuddyWater Reloaded: DLL Side-Loading Analysis & Hunting Tips
Just saw the write-up from Symantec and Carbon Black regarding MuddyWater's latest campaign. They are actively targeting manufacturing and government sectors across nine countries using good old DLL side-loading. While we see this technique often with APT groups, MuddyWater's persistence in Q1 2026 is impressive—and worrying for the supply chain.
The vector typically involves placing a malicious DLL (often masquerading as version.dll or windowscodecs.dll) in the same directory as a legitimate, signed executable. When the app runs, it loads the malicious code, giving them a foothold without triggering standard executable alerts.
Since there isn't a specific CVE to patch here, we have to rely on behavioral detection. I've been tuning our SIEM to flag when signed binaries load unsigned DLLs from user-writable directories. Here is a KQL query I'm currently deploying to hunt for this behavior in Microsoft Sentinel:
DeviceImageLoadEvents
| where InitiatingProcessVersionInfoCompanyName != "Microsoft Corporation"
| where FileName endswith ".dll"
| where FolderPath contains @"C:\Users\" or FolderPath contains @"C:\ProgramData\"
| where IsSigned == false
| project Timestamp, DeviceName, InitiatingProcessFileName, FileName, FolderPath, SHA1
| order by Timestamp desc
Has anyone else observed specific IOCs for this campaign in their telemetry? How are you balancing detection rules for side-loading without drowning in false positives from legitimate software installers?
Great post. We've had success targeting Sysmon Event ID 7 specifically for this. The key is excluding standard paths like System32 but strictly monitoring %AppData% and %Temp%. We also check the Authenticode signature status immediately. If a known signed binary like excel.exe or a custom utility is loading a DLL from Downloads that has Valid=false, it's game over for that endpoint—we automatically isolate.
From a sysadmin perspective, AppLocker has been a lifesaver against side-loading. We block unsigned DLLs by default in user directories. It breaks a few legacy apps, but the security trade-off is worth it. You can also use PowerShell to audit these paths quickly if you don't have an EDR deployed:
Get-ChildItem -Path "C:\ProgramData" -Recurse -Filter *.dll | Get-AuthenticodeSignature | Where-Object { $_.Status -ne 'Valid' }
On the red team side, we see DLL side-loading evading AV because the parent process is trusted. It’s trivial to generate a proxy DLL with tools like SharpDllProxy that exports all the original functions. If you aren't monitoring for the specific file modifications or the unsigned loads, it's invisible. I'd recommend looking for the creation of the DLL file moments before the process execution, not just the load event itself.
Solid advice from the EDR/AppLocker side. To supplement, we've found network correlation helpful; the side-loading is usually followed immediately by C2 check-in. If you need a quick triage script for suspected hosts without heavy logging, try scanning for specific modules loaded in memory:
Get-Process -IncludeUserName | ForEach-Object { $_.Modules | Where-Object { $_.FileName -match "windowscodecs.dll" -and $_.FileName -notmatch "C:\\Windows" } } | Select-Object ProcessName, FileName
Verified Access Required
To maintain the integrity of our intelligence feeds, only verified partners and security professionals can post replies.
Request Access