MuddyWater's 2026 Refresh: DLL Side-Loading Targeting Manufacturing
Hey team,
Just caught the latest report from the Threat Hunter Team regarding MuddyWater's Q1 2026 activity. It looks like they are continuing their trend of targeting critical sectors—specifically industrial manufacturing, electronics, and finance—across nine different countries.
The core of their initial access still relies heavily on DLL side-loading. They aren't reinventing the wheel, but they are refining the delivery. The campaign leverages signed, legitimate binaries to load malicious DLLs, effectively bypassing standard application allow-listing that trusts the signed parent process.
For those hunting for this, you'll want to focus on Sysmon Event ID 7 (Image Loaded). Look for signed executables loading DLLs from suspicious user directories or AppData rather than their legitimate installation paths.
Here is a basic KQL query to start hunting for anomalies in Image Load events:
DeviceImageLoadEvents
| where InitiatingProcessFileName in~("target_legitimate_app.exe")
| where FolderPath contains @"\AppData\Local\"
| where SHA256 !in (KnownGoodHashes)
| project Timestamp, DeviceName, InitiatingProcessFileName, FileName, FolderPath, SHA256
The key is identifying which specific binaries are being abused in this wave (often utilities like password recovery tools or custom local software) and monitoring them closely.
How are you guys handling the detection gap for signed binaries loading unsigned payloads from user-writable directories? Are you relying purely on telemetry, or has anyone had success with strict AppLocker/WDAC policies in these manufacturing environments where legacy software is rampant?
In our SOC, we've moved to blocking specific vulnerable binaries known to be abused for side-loading via ASR rules, even if they are signed. It's aggressive, but it works. We also correlate the image load events with network connections within 5 minutes. If a utility app loads a DLL from Temp and then hits a C2 server, it's an instant kill switch.
# Example ASR rule check (Audit mode first)
Set-MpPreference -AttackSurfaceReductionRules_Ids 01443614-c584-4bef-a61a-b69b8a9afc98 -AttackSurfaceReductionRules_Actions Enabled
Strict WDAC is the only real fix, but getting approval in a manufacturing plant with legacy PLC software is a nightmare. We're currently piloting a 'allow-list' approach for the C:\Program Files directory and explicitly denying AppData for any process that shouldn't be writing memory there. The noise is high, but MuddyWater's PowerShell stagers usually stick out like a sore thumb if you have Script Block Logging turned on.
Since WDAC is often a non-starter with legacy OT gear, we rely heavily on Sysmon for the kill chain. Specifically, tracking unsigned DLLs loaded by signed processes helps spot side-loading without breaking production. You can tune it to target just the vulnerable binaries identified in the report.
Here's a snippet to get started:
false
true
Does anyone else find high alert volume with this, or do you limit the scope strictly to directories outside C:\Windows?
To add to Diana's point, simply flagging unsigned DLLs can generate a lot of noise. We've had better success focusing on the source path of the loaded module. If a signed binary loads a DLL from AppData or Temp, it is almost always malicious intent. Here is a quick KQL query we use to hunt for this behavior:
DeviceImageLoadEvents
| where FolderPath has_any (@'\AppData\', @'\Temp\')
| where InitiatingProcessVersionInfoSignatureState == "Valid"
| project DeviceName, InitiatingProcessFileName, FileName, FolderPath
Verified Access Required
To maintain the integrity of our intelligence feeds, only verified partners and security professionals can post replies.
Request Access