An Iranian intelligence service has been running the same six-step intrusion since 2017. The tooling has been rebuilt four times, PowerShell, then your own IT software, then custom C++, now Rust. If your detection is built around what the malware looks like, you have been a year behind this group for a decade.
The email arrives on a Tuesday morning, and there is nothing wrong with it.
It's an invitation to a webinar, a regional energy policy briefing, exactly the kind of thing Sana attends twice a year as a procurement analyst at a gas utility. The sender's domain looks right. The formatting is professional. There's an attached agenda, a Word document, and when she opens it Word asks whether she wants to enable content.
She does. Nothing appears to happen.
Something did. A single command has run in the background, and by the end of the week an Iranian intelligence service will have mapped her company's Active Directory, harvested credentials from four servers, opened an encrypted tunnel out through a port her firewall trusts, and begun quietly reading the commercial documents her employer negotiates contracts with.
This isn't a hypothetical shape. Webinar and course invitations are a documented MuddyWater lure. And in October 2025 alone, a single MuddyWater campaign was reported to have targeted more than a hundred organisations, with recent activity spanning government ministries, telecommunications operators, and, in the United States, a bank, an airport, and a software company.
The Group With Ten Names and One Habit
MuddyWater is a state-sponsored espionage operation attributed by US Cyber Command and a five-agency CISA-led advisory to Iran's Ministry of Intelligence and Security. It has been active since at least 2017.
It is tracked under at least ten different names across the security industry, Seedworm, MERCURY, Mango Sandstorm, Static Kitten, Earth Vetala, TEMP.Zagros, TA450, and others, which tells you something in itself: this group has been rediscovered, renamed, and re-profiled by nearly every major vendor, repeatedly, for years. Everyone knows about them. They keep getting in anyway.
Two details about how they operate matter more than the name.
They don't only spy, they resell. Once inside, MuddyWater steals data and establishes backdoor access for operatives, and it sometimes shares that access with other threat actors. So the damage doesn't necessarily end when they lose interest in you. Your network can become someone else's starting position.
They have used ransomware. This is primarily an espionage group, but not exclusively, and recent campaigns show a drift toward disruption alongside intelligence collection. Treating them as a quiet, read-only problem is a planning error.
Here is what most threat briefings miss, and it's the reason MuddyWater is worth studying even if Iran isn't in your threat model.
Trace their tooling across a decade:
Read that sequence again, because it contains a warning.
Every retooling was a response to defenders catching the previous tool. PowerShell logging got better, so they leaned on legitimate RMM software. EDR learned to flag RMM abuse, so they wrote custom C++. Now that's known, so they've moved to Rust. This is not a group that innovates for the pleasure of it. It innovates exactly as much as it must, one step ahead of whatever signature you deployed last year.
Which means a detection strategy built on what the malware is has a structural flaw: it is always calibrated to the generation you already survived.
Now look at what didn't change. Across all four eras, the attack is the same six moves:
phish or exploit your way in → run something → make it survive a reboot → map the domain and steal credentials → tunnel out to a place you control → collect, compress, and take the data.
Ten years. Four toolkits. One behaviour.
There's a second constant, and it's less flattering to defenders. MuddyWater's other favourite entry route is exploiting public-facing applications, Exchange via ProxyShell and ProxyLogon, Fortinet appliances, Log4Shell, and the MSDT flaw known as Follina (CVE-2022-30190). Every one of those is a known vulnerability with a published patch. A government intelligence service is walking into enterprise networks through doors the industry has been shouting about for years.
You cannot out-signature an adversary who rewrites their tools annually. You can catch a sequence of behaviour that has not changed since 2017. That is the entire defensive argument, and it's what the rest of this piece is about.
Follow Sana's Tuesday morning through to the end, and one more person: Marcus, the IT administrator whose daily toolkit the attacker is about to borrow. Marcus matters, because almost everything that happens next is designed to look exactly like Marcus doing his job.
What the attacker does. The webinar lure lands in Sana's inbox with a macro-enabled Word document, a macro being the small automation script Office documents can carry, and the group's most reliable entry point. If phishing fails, they go around it: scanning for an unpatched Exchange server or Fortinet appliance and exploiting a published vulnerability instead. Some lures skip macros entirely and use Follina, which abuses a Windows diagnostic tool so that merely opening the document is enough.
Where Invinsense steps in. The SIEM, the system that pools email, endpoint, identity, and network logs into one place, watches inbound mail for Office documents and archives arriving from external senders, particularly those impersonating government bodies, IT departments, or known vendors. But the decisive detection is behavioural, not reputational: the moment Word or Excel spawns a child process it has no business spawning, mshta.exe, wscript.exe, rundll32.exe, powershell.exe, or in the Follina case msdt.exe, SIEM and EDR (endpoint detection and response) kill the process chain and quarantine the endpoint. Sana's Word document is allowed to be a document. It is not allowed to be a launcher.
Note what this does not depend on: knowing what the payload is. Word spawning msdt.exe was suspicious in 2022 and is suspicious in 2026, regardless of whether the thing it fetches is written in PowerShell, C++, or Rust.
What the attacker does. The first-stage backdoor runs. Historically that meant obfuscated PowerShell; today it may be a compiled implant delivered by a loader. Either way they lean on LOLBins, "living off the land binaries," legitimate Windows programs like mshta.exe and rundll32.exe that can be repurposed to run attacker code, so nothing unfamiliar has to touch the disk. Their signature evasion technique is DLL side-loading: dropping a malicious DLL next to a legitimate, signed executable so the trusted program loads the attacker's code for them.
Where Invinsense steps in. Three detections stack here. First, PowerShell is invoked with the flags that betray intent, -enc or -EncodedCommand (a hidden, encoded instruction), -nop, -w hidden, -ExecutionPolicy Bypass. Legitimate administrators rarely need to hide, disable, and bypass all at once. Second, DLL side-loading: EDR cross-references a signed executable against the DLLs it's expected to load, and treats a known-good binary pulling an unsigned DLL from a temp folder or user profile directory as critical. Third, LOLBin execution in contexts that make no sense, rundll32.exe launched as a child of Word, for instance.
What the attacker does. They make sure a reboot doesn't evict them: a Registry Run key (an entry that tells Windows to launch something at every login), a scheduled task, a script dropped into the Startup folder, a hijacked PowerShell profile, or COM object hijacking, quietly registering their code as a component Windows will load on its own.
Where Invinsense steps in. The SIEM watches for new scheduled tasks (Windows Event ID 4698) and for modifications to the Run keys under HKCU\Software\Microsoft\Windows\CurrentVersion\Run and its machine-level equivalent, by any process that isn't a recognised system or IT management process. It escalates hard when the new task or key points at a PowerShell script, an encoded command, or an executable sitting in a user-writable path, a .ps1 file in an AppData folder has no legitimate reason to be launching itself at every login. On confirmation, the Run key is removed and the host isolated automatically.
The honest limit: Run keys and scheduled tasks are high-coverage with automated removal. COM object hijacking is medium coverage. The SIEM monitors for unexpected COM registrations in the user-writable part of the registry, which is precisely where MuddyWater puts them, since it avoids needing admin rights, but distinguishing a malicious registration from a legitimate one requires a baseline of what normal looks like in your specific environment. That baseline is built during onboarding. Until it exists, this is a weaker link than the other two, and it's worth knowing that going in.
What the attacker does. Now they learn the terrain. ADFind and BloodHound map Active Directory, who the administrators are, which groups matter, which machines are worth reaching. They pull credentials out of LSASS, the Windows process holding live passwords and tokens in memory, and harvest saved passwords with LaZagne. Then they move sideways over RDP and SMB using those stolen credentials, logging in, not breaking in.
Where Invinsense steps in. This is where Marcus becomes the story. The attacker's goal is to look like him: an administrator, connecting to servers, at odd hours, which Marcus genuinely sometimes does.
The platform separates them on behaviour. EDR alerts on any process opening lsass.exe with read or full-access rights when that process isn't a known security tool, and on LSASS dump files (.dmp) appearing in temp or user directories. The SIEM flags abnormal LDAP enumeration, the directory-wide sweep that ADFind and BloodHound generate, which no real user produces by hand.
And UEBA (User and Entity Behaviour Analytics, a learned baseline of how each account normally behaves) catches the movement itself: a credential authenticating to a machine it has never touched before, a single account appearing on two geographically distant hosts within minutes, RDP originating from a workstation rather than a jump host.
The chaining is what makes it decisive. If the account now moving laterally is the same one that recently had a password reset, logged in from an unusual location, or sat at the end of a phishing event, the platform escalates immediately rather than treating it as one more admin login.
Correlating internal NetFlow and NDR data with endpoint telemetry and Windows logon events, Invinsense reconstructs the full east-west path, which account hopped to which host, in what order, and SOAR blocks the RDP session and forces MFA re-authentication.
Marcus logs into servers. Marcus has never logged into all of them, in nine minutes, from Sana's laptop.
What the attacker does. They need a durable channel out. MuddyWater's toolkit here is deliberately boring: reverse tunnels built with Ligolong or Chisel (reverse tunnel meaning the connection is initiated from inside your network outward, so the firewall sees an ordinary outbound session rather than an inbound intrusion), C2 frameworks like PhonyC2, DNS-over-HTTPS as a covert channel, and, cleverest of all, corporate messaging APIs. Instructions and stolen data move through Slack or Telegram, because traffic to those services is traffic your firewall was configured to allow.
They also install legitimate remote administration software as a second way in, precisely because it blends with real IT support activity.
Where Invinsense steps in. The tunnels have a shape even when the contents are encrypted. The platform flags internal hosts, especially workstations that have no business doing this, establishing outbound SSH sessions on ports 443, 8080, or 8443 rather than the standard port 22. Long-lived, low-bandwidth connections with a regular beaconing rhythm to an unfamiliar external IP are a covert channel, not a user browsing. NDR and EDR together catch the Ligolo-ng and Chisel agents and terminate the session.
For the RMM problem, the answer is inventory rather than reputation: detect execution of AnyDesk, TeamViewer, SimpleHelp, or ScreenConnect that is not on your approved software list, with particular weight when it launches from a Downloads or temp folder, or as a child of PowerShell or cmd. This is Marcus's own category of tool, which is exactly why the whitelist, not the tool's legitimacy, has to be the deciding factor.
What the attacker does. Keylogging and screenshot capture. Credential harvesting with LaZagne. Files staged in temp directories, compressed with 7-Zip and password-protected so inspection tools can't read them, then pushed out through the C2 channel or to cloud storage. Then the cleanup: clearing Windows event logs, and creating a new account or quietly adding one to Domain Admins so they still have a way in after you've cleaned up the malware.
Where Invinsense steps in. EDR detects the keylogging and screen-capture behaviour and terminates the process, and catches LaZagne executing and dumping saved passwords. The SIEM alerts when a host transfers unusually large volumes of data to an external destination it has never communicated with, and, crucially, correlates that with file access: the same host having just touched large numbers of sensitive files or email archives turns a volume anomaly into a high-confidence exfiltration finding.
Two late-stage detections matter disproportionately. Event ID 1102 (Security log cleared) or 104 (System log cleared), from any host outside an approved rotation process, fires immediately at high severity, log clearing is not a step in any legitimate workflow, and it means the intrusion is already well established. And every account creation and privileged group change in Active Directory is monitored: a new account added to Domain Admins or Enterprise Admins, outside a change window, by an account with no history of provisioning users, is disabled on the spot and escalated with full event context.
On any confirmed high-severity detection, SOAR runs the same playbook regardless of the hour: disable the account, isolate the host, capture forensic evidence, alert the SOC.
Look back at what actually triggered each stage.
Word spawned a process it shouldn't. PowerShell ran hidden and encoded. A signed binary loaded a DLL from the wrong folder. A .ps1 file registered itself to launch at login. A credential appeared on a host it had never touched. A workstation opened a long-lived SSH session on port 443. Event log 1102 fired.
Not one of those detections asks what the malware is called. Not one would have been weakened by MuddyWater's move from PowerShell to C++ to Rust. That's the point of behavioural detection against this particular adversary: you are watching the part of the attack that has been stable for a decade, rather than the part they rewrite every eighteen months.
Individually, each signal is arguable. A busy admin could produce two or three. Chained — a phishing email, then a hidden PowerShell, then a new Run key, then a lateral hop, then a tunnel to an unknown IP — they stop being arguable and become a narrative, while there is still time to end it.
Three honest limits.
The patch gap isn't a detection problem. When MuddyWater walks in through an unpatched Exchange server or a Fortinet appliance with a published CVE, detection is the second line of defence and it's already a worse position than the first. No SIEM makes vulnerability management optional. If your public-facing applications are behind on patches, this group has a route in that no amount of correlation removes, it only shortens how long they enjoy it.
COM object hijacking is medium coverage until baselining is done. Stated plainly above, and worth repeating here because it's the weakest link in an otherwise strong persistence story.
Encrypted covert channels are hard. DNS-over-HTTPS and messaging-API abuse are detectable by rhythm, destination, and volume, not by reading the contents, which are encrypted by design and which your organisation legitimately uses all day. Detection here is inference, and inference has a false-negative rate. Anyone claiming certainty on encrypted C2 is selling something.
And a fourth thing, which isn't a product limitation but belongs in the same paragraph: because MuddyWater shares access with other operatives, evicting them is not the same as being finished. Assume the access was passed on, and hunt accordingly.
For nearly a decade this group has been named, profiled, sanctioned, and published on by every major vendor in the industry. Their targets know they exist. And they still get in. This is because they are patient enough to rewrite their tools every time we learn the old ones, and also because we keep leaving known doors unlocked.
That's the lesson worth taking, and it outlives MuddyWater entirely. If your detection is built around what the malware is, you are defending against last year's version of your adversary. They know that. It's why the tools keep changing.
The behaviour doesn't. Word doesn't spawn msdt.exe. Administrators don't hide, encode, and bypass in the same command. Credentials don't appear on twelve machines in nine minutes. Nobody clears the Security log for a good reason.
So the question isn't "do we have a signature for their latest implant?"
It's "when the next rewrite lands, and it will, would we still see the shape of what they're doing?"
Discover complete cybersecurity expertise you can trust and prove you made the right choice!
