MuddyWater: PowerShell, Remote-Management Tools, and Iranian Espionage

MuddyWater is a useful case study in why modern threat detection cannot be reduced to finding “bad tools.” Public reporting repeatedly connects the group with phishing, PowerShell, legitimate remote-monitoring and management software, custom backdoors, and ordinary cloud or file-sharing services. Many of those technologies also support normal business operations. The defender’s task is therefore to identify unauthorized intent through context: who ran the tool, how it arrived, what it contacted, and what happened next.

Executive Answer

MuddyWater is an Iranian cyberespionage group that U.S. authorities assess to be subordinate to Iran’s Ministry of Intelligence and Security. Active since at least 2017, it has targeted government and private organizations across the Middle East and other regions. Its reported tradecraft combines spearphishing, PowerShell, legitimate remote-monitoring and management tools, custom malware, credential access, and data collection. Defenders should not treat PowerShell or RMM software as malicious by default; they should correlate authorization, process ancestry, identity, network destinations, installation history, and follow-on behavior to distinguish administration from intrusion.

Key Takeaways

• MuddyWater is primarily associated with espionage and persistent access, although public reporting also describes access sharing and operations with disruptive potential.
• Mango Sandstorm, MERCURY, Seedworm, Static Kitten, TEMP.Zagros, Earth Vetala, and TA450 are widely associated labels, but their exact scopes depend on the source.
• PowerShell and RMM tools are attractive because they are capable, familiar, and often trusted inside enterprises.
• The strongest detections combine identity, endpoint, network, email, and remote-management telemetry.
• An approved tool used by an unexpected identity, from an unusual installer source, at the wrong time, and followed by credential or collection activity should be treated as a behavioral chain not an isolated event.
• Durable controls matter more than a static list of domains, hashes, or product names.

Who Is MuddyWater?

MuddyWater is the industry name for a long-running Iranian cyberespionage activity set. U.S. Cyber Command and partner agencies describe it as a subordinate element within Iran’s Ministry of Intelligence and Security, or MOIS. A 2022 joint government advisory said the actors conducted espionage and other malicious operations against government and private-sector organizations in telecommunications, defense, local government, oil and natural gas, and other sectors across several regions.

The label belongs inside a broader ecosystem of Iranian APT groups, but it should not be used as shorthand for every Iran-linked intrusion. Different organizations may share a sponsor, tools, infrastructure providers, targets, or access without being the same operating team.

MuddyWater also illustrates an important distinction in state-sponsored hacking: sophistication is not always expressed through a unique zero-day or a never-before-seen implant. A patient operator can create strategic impact by combining social engineering, valid accounts, scripts, remote access, and commercially available services.

MuddyWater Names and Aliases

Threat-intelligence providers name the activity they can observe. One vendor may cluster phishing infrastructure, another may track malware deployments, and another may focus on a government program. The following labels are useful cross-references, not a guarantee that every provider sees an identical set of operators and campaigns.

The maintained MITRE ATT&CK MuddyWater profile lists these associated groups and, as of its July 31, 2026 modification, also reflects newer source material. ATT&CK is an excellent index of reported behavior, but it is not proof that every technique occurred in one campaign or remains active today.

Attribution: What Is Firm and What Remains Analytical?

The strongest public organizational statement comes from U.S. government reporting that identifies MuddyWater as subordinate to MOIS. That is a named government assessment. It is stronger than an inference based only on language, victim geography, or malware similarity, but it is still best described with attribution language such as “assesses,” “attributes,” or “links.”

Campaign-level attribution remains more granular. A shared code-signing certificate, RMM product, hosting provider, PowerShell pattern, or victim sector can support an assessment, but none is sufficient alone. Analysts should record which source made a claim, when it was made, what evidence was visible, and whether later research narrowed or challenged the relationship.

This discipline prevents two common errors: collapsing separate Iranian groups into one actor and attributing ordinary criminal or administrative behavior to MuddyWater merely because the same tool appeared.

What Does MuddyWater Target?

Public reporting since 2017 covers government bodies and organizations in telecommunications, defense, finance, energy, oil and gas, technology, education, manufacturing, aviation, and nonprofit sectors. The Middle East has been a persistent focus, but reporting also documents activity affecting organizations in Asia, Africa, Europe, and North America.

Target lists should be treated as observed samples, not a closed universe. An organization’s practical risk depends on its strategic information, regional relationships, exposed systems, suppliers, remote-access pathways, and high-risk personnel. Sector relevance can raise priority, but it does not establish that an organization has been targeted.

A Condensed MuddyWater Timeline

The timeline is a selection of defensively meaningful reporting. It is not a complete incident ledger, and adjacency between rows does not prove one continuous campaign.

Why PowerShell Appears So Often

PowerShell is a legitimate Windows automation and administration framework. It can query systems, manage services, interact with the registry, retrieve content, and orchestrate other tools. Those same capabilities make it attractive after a foothold, especially when an operator wants to use technology already accepted in an enterprise.

This is a classic living-off-the-land problem: the binary name is a weak signal because administrators, software-management platforms, security products, and attackers may all invoke it. Context determines whether the execution is expected.

For MuddyWater, public sources have described PowerShell in several roles: script execution, payload retrieval, backdoor functionality, command-and-control logic, obfuscation, and installation of remote-management software. Defenders should treat those as historically reported capabilities, not as a promise that every current intrusion will use PowerShell.

High-Value PowerShell Context

Useful questions include:

• Which parent process launched PowerShell: an approved management platform, a signed internal script host, an Office application, a browser, an archive utility, or an unusual temporary executable?
• Was the user expected to run administrative automation, and did the account normally have that privilege?
• Was the script signed, stored in an approved repository, and associated with a documented change?
• Did execution immediately create a service, scheduled task, remote agent, tunnel, archive, or outbound connection?
• Did the host recently receive a suspicious email, collaboration message, or download?
• Was script-block, module, process, and endpoint telemetry collected before containment?

The goal is not to alert on every PowerShell process. It is to detect improbable combinations that make legitimate-looking execution meaningful.

Why Remote-Management Tools Matter

RMM and remote-support products help administrators maintain fleets of computers, deploy software, troubleshoot incidents, and support customers. They are not malware. Once an attacker can install or enroll an agent, however, the same product may provide persistent remote control, file transfer, command execution, and a communication channel that resembles approved IT traffic.

Proofpoint’s 2025 research described a TA450 ClickFix campaign in which a security-themed email persuaded recipients to launch PowerShell and install Level RMM. The researchers also cited prior TA450 use of Atera, PDQ Connect, ScreenConnect, and SimpleHelp. The exact product can change; the durable issue is unauthorized remote administration.

This pattern intersects with the human risk documented in DeepStrike’s phishing research. A plausible security update, trusted mailbox, PDF link, file-sharing service, or support pretext can move a user past controls without exploiting a new software vulnerability.

If the actor already has a password, repeated or manipulated authentication prompts can add another layer of social pressure. Controls designed for MFA fatigue and prompt abuse therefore complement endpoint and RMM monitoring, even though MFA fatigue is not a universal MuddyWater signature.

The Recurring Access-to-Collection Chain

Public campaigns vary, but a defensively useful model has six stages.

1. Targeting and pretexting: An email or message is tailored to a role, event, business workflow, or security concern.
2. Initial access: A link, attachment, compromised account, or known exposed weakness creates an opening.
3. Execution and remote access: Scripts, loaders, or an RMM installer establish usable control.
4. Persistence and discovery: The operator preserves access and learns about hosts, accounts, security tools, and network structure.
5. Credential access and collection: Credentials, browser data, files, screenshots, or other intelligence are gathered according to the operation.
6. Exfiltration or access handoff: Data or continuing access may be moved through attacker infrastructure, legitimate cloud services, remote tools, or another operator.

Each stage offers a different telemetry source. Email and browser events clarify delivery; identity logs clarify account use; endpoint data clarifies process and service activity; RMM consoles clarify enrollment and operator sessions; network and cloud logs clarify destinations and transfers. Correlation is far stronger than a single alert.

How MuddyWater Tradecraft Evolved in 2025–2026

The “PowerShell plus RMM” description remains useful, but it is no longer sufficient. ESET’s December 2025 MuddyWater research described continued spearphishing and RMM delivery alongside newer custom tools, credential-stealing components, loaders, reverse tunnels, and a backdoor called MuddyViper. It also reported a defined operational overlap with Lyceum, described as an OilRig subgroup, and cautiously suggested that MuddyWater may have provided initial access in that observed activity.

Broadcom/Symantec’s March 2026 Seedworm incident reporting described activity at a U.S. bank, airport, nonprofit organizations, and the Israeli operations of a U.S. software company. Researchers reported a Deno-based backdoor named Dindoor, a Python backdoor named Fakeset, and an attempted transfer to cloud storage in one environment; they did not claim a complete global victim count or confirm that the attempted exfiltration succeeded.

The defensive lesson is continuity plus adaptation. Security teams need controls for familiar scripts and RMM agents, but they must also detect unusual runtimes, new services, unexpected signed binaries, cloud-transfer utilities, credential access, and data staging. A product-denylist alone will age quickly.

MuddyWater and MITRE ATT&CK

ATT&CK mappings summarize techniques reported across multiple years and sources. They are useful for coverage assessment, not for identifying an actor from one event.

Coverage should be tested as a chain. A medium-confidence phishing alert becomes more serious when the same user launches an unusual script, installs a new remote agent, and creates an outbound session to an unapproved tenant.

The DeepStrike Admin-Tool Trust Matrix

The following matrix turns “is this tool bad?” into a context-based decision.

No single row proves MuddyWater. Several red-state signals in sequence justify containment even when attribution is unknown.

Detection Priorities

1. Govern RMM Before Detecting It

Build a complete list of approved remote products, versions, tenants, relay domains, deployment channels, owners, service accounts, and expected support windows. Block or require approval for alternatives. Alert when a second remote tool appears on a host that already has an authorized agent.

Treat MSP and vendor access as part of the same inventory. Their agents, accounts, and support workflows extend your attack surface, so they belong in continuous attack surface management, identity review, and incident exercises.

2. Collect the Telemetry That Gives Scripts Meaning

Retain process creation with parent-child relationships, command-line metadata according to policy, PowerShell script-block and module events, AMSI or equivalent inspection, file-origin data, service and task creation, and EDR events. Protect logs from alteration and synchronize time across systems.

Focus analytics on sequences: an Office application or browser produces a download; an unexpected user launches PowerShell; a new service appears; an RMM agent connects; discovery or collection follows. Tune against approved deployment patterns instead of suppressing the entire tool.

3. Join Identity and Endpoint Evidence

Investigate successful sign-ins after distributed failures, unusual device or geography changes, new MFA registrations, session-token anomalies, and privilege use that does not fit the user’s role. Correlate these events with downloads, remote-tool sessions, and endpoint actions.

Phishing-resistant MFA, conditional access, disabled legacy authentication, strong account recovery, and limited admin paths reduce opportunity. They do not remove the need to monitor valid sessions after compromise.

4. Watch Egress and Cloud Transfer in Context

Baseline outbound destinations for remote agents, file-sharing platforms, object storage, tunnels, and synchronization tools. Alert when a rarely used transfer utility appears on a sensitive host, especially after credential access or archive creation.

Do not block a cloud provider solely because it appeared in one report. Determine which enterprise accounts, buckets, tenants, applications, and destinations are authorized, then detect deviations.

5. Preserve Behavior-Led Hunts

Campaign IOCs expire. Keep them as time-bounded investigative leads, but build durable hunts around delivery, process ancestry, unauthorized service creation, remote-agent enrollment, credential access, data staging, and unusual outbound transfers.

Mitigation Roadmap

Reducing internet-facing exposure still matters because public reporting also includes exploitation of known vulnerabilities. A mature program combines asset discovery, prioritized patching, identity security, email defenses, endpoint visibility, remote-access governance, and tested recovery.

Incident Response: Suspicious PowerShell or an Unknown RMM Agent

1. Validate authorization without trusting the endpoint. Check the CMDB, RMM tenant, support ticket, change record, and asset owner through an independent channel.
2. Preserve evidence. Capture the endpoint and identity timeline, installer provenance, process tree, service or task details, remote sessions, relevant logs, and network destinations before destructive cleanup.
3. Contain proportionately. Isolate the affected host or restrict its network access, suspend unauthorized remote sessions, and block further deployment while maintaining responder access.
4. Secure identities. Revoke active sessions, reset affected credentials, review MFA and account-recovery changes, and inspect privileged and service accounts used from the host.
5. Scope beyond one device. Search for the same installer, tenant, service, account, parent process, destination, and follow-on behaviors across endpoints, cloud, email, and network logs.
6. Hunt for persistence and collection. Review new tasks, services, startup mechanisms, remote tools, tunnels, credential access, archive creation, and unusual file or mailbox access.
7. Assess data impact. Determine what information was accessed, staged, or transferred and whether notification obligations may apply.
8. Recover from a known-good state. Remove unauthorized access, rebuild when integrity is uncertain, rotate exposed secrets, restore normal operations, and monitor for recurrence.

These actions should be executed through a tested incident response plan with named authority, evidence handling, legal escalation, communications, and recovery criteria.

MuddyWater vs. Other Iranian Threat Actors

MuddyWater is not the same maintained activity set as OilRig/APT34. Microsoft publicly maps them to Mango Sandstorm and Hazel Sandstorm, respectively, while MITRE maintains separate group records. ESET’s report of cooperation with a subgroup associated with OilRig is evidence of an observed relationship, not proof that the groups should be merged.

MuddyWater is also distinct from Charming Kitten/APT35 and APT42 in maintained public taxonomies. Those actors may share Iranian strategic interests, phishing behavior, regional targets, or infrastructure choices, but those similarities do not establish identity.

For defenders, the actor comparison affects intelligence analysis more than first response. Contain suspicious access based on evidence; refine attribution after the environment is stable.

Common Mistakes

• Blocking PowerShell everywhere: This may disrupt administration while encouraging attackers to switch tools. Constrain privilege and detect abnormal context instead.
• Calling every RMM agent malware: The product may be legitimate even when the installation or operator is not.
• Attributing from one artifact: A certificate, domain registrar, file-sharing service, or tool name is rarely enough.
• Using old IOCs as the main control: Infrastructure rotates, while behavioral relationships persist.
• Ignoring the RMM control plane: Endpoint evidence alone may not reveal tenant ownership, operator identity, or session history.
• Cleaning one host and closing the incident: Remote access, credentials, email accounts, MSP pathways, and cloud sessions can extend the compromise.
• Equating operational overlap with identity: Collaboration, access handoff, shared suppliers, or criminal tooling can blur cluster boundaries.

Validate the Defenses, Not Just the Documentation

Tabletop exercises test decisions, but technical validation shows whether controls actually fire. A controlled red-team-versus-blue-team exercise can measure whether a realistic social-engineering-to-remote-access chain is detected and contained.

A narrower penetration testing engagement is appropriate when the immediate goal is to validate defined external, identity, application, cloud, or network attack paths. Full adversary emulation is more appropriate when the objective is to test cross-domain detection and response over time.

Any exercise should have written authorization, explicit rules of engagement, safe objectives, protected evidence, and a retest plan. It should emulate behaviors relevant to the organization without reproducing uncontrolled malware or real-world infrastructure.

Frequently Asked Questions

What is MuddyWater?

MuddyWater is an Iranian cyberespionage activity set reported since at least 2017. U.S. government sources assess it to be subordinate to Iran’s Ministry of Intelligence and Security. Public reporting associates it with phishing, scripts, legitimate remote-management tools, custom malware, credential access, intelligence collection, and persistent access.

Is MuddyWater the same as Mango Sandstorm?

Microsoft maps MuddyWater-related activity to Mango Sandstorm, and MITRE lists Mango Sandstorm as an associated group for G0069. The names are practical cross-references, but analysts should still preserve the scope and dates of the source they are citing because vendors may observe different portions of an operation.

Is MuddyWater the same as APT34 or OilRig?

No, not in maintained public taxonomies. Microsoft maps OilRig/APT34 to Hazel Sandstorm and MuddyWater to Mango Sandstorm, while MITRE maintains separate profiles. Reports of cooperation or operational overlap do not make the groups identical.

Why does MuddyWater use PowerShell?

PowerShell is already present in many Windows environments and supports powerful administration and automation. Public reporting describes MuddyWater using it for execution and supporting intrusion activity. Its legitimate use means defenders need process, identity, script, and network context rather than a blanket assumption that every PowerShell event is malicious.

Are Atera, ScreenConnect, SimpleHelp, PDQ, Level, or other RMM tools malicious?

No. They are legitimate administration and support products. Risk appears when an unauthorized person installs, enrolls, or controls them, or when their use does not match an approved tenant, operator, ticket, deployment path, or business purpose.

Which organizations should prioritize MuddyWater defenses?

Government, telecommunications, defense, energy, finance, technology, aviation, manufacturing, education, nonprofit, and MSP-connected organizations appear in public reporting. Any organization with strategically valuable data, regional exposure, internet-facing systems, high-risk users, or weak remote-access governance should prioritize the underlying behaviors.

What is the best way to detect MuddyWater activity?

There is no single definitive signal. The strongest approach correlates phishing or download evidence, unusual PowerShell ancestry, unauthorized RMM enrollment, identity anomalies, new services or tasks, credential access, data staging, and outbound transfers. That chain can justify response even before an actor attribution is available.

Conclusion

MuddyWater’s enduring lesson is not that one script engine or remote product is dangerous. It is that trusted administration becomes risky when authorization, provenance, identity, destination, timing, and behavior stop lining up.

Build an approved baseline, preserve cross-domain telemetry, and respond to chains rather than isolated tool names. Then test whether the controls work under pressure. DeepStrike’s Red Teaming Services can emulate relevant behaviors under a controlled scope and turn missed detections into prioritized, retestable improvements.

About The Author

Mohammed Khalil is a Cybersecurity Architect at DeepStrike, specializing in advanced penetration testing and offensive security operations. With certifications including CISSP, OSCP, and OSWE, he has led numerous red team engagements for Fortune 500 companies, focusing on cloud security, application vulnerabilities, and adversary emulation. His work involves dissecting complex attack chains and developing resilient defense strategies for clients in the finance, healthcare, and technology sectors.