DinDoor and ChainShell tie MuddyWater to Russian malware-as-a-service infrastructure

MuddyWater appears to be using commercial malware-as-a-service infrastructure rather than relying only on its own tooling. New research from JUMPSEC says the Iranian espionage group used a shared TAG-150 platform tied to DinDoor, ChainShell, and CastleRAT-related infrastructure, while Broadcom previously linked the DinDoor MSI delivery chain to Seedworm, also known as MuddyWater.

The key point is attribution. JUMPSEC argues that MuddyWater did not build the Deno-based malware family itself. Instead, it likely operated as a customer of a Russian-speaking malware service, using shared infrastructure and campaign-specific credentials to run its own operations. That distinction matters because the same platform appears to support more than one threat actor.

Broadcom’s March 5 report already tied the “Amy Cherne” and “Donald Gay” code-signing certificates to Seedworm activity and said those certificates signed DinDoor-related MSI installers. JUMPSEC extends that chain by linking the same certificate and JWT campaign data to wider TAG-150 infrastructure and to a previously undocumented malware component it named ChainShell.

How the link was made

JUMPSEC says one of its strongest findings came from a PowerShell script named reset.ps1 discovered on infrastructure it attributes to MuddyWater. According to the report, that script installs Node.js, decrypts an embedded payload, and deploys ChainShell, which the researchers describe as a JavaScript-based malware agent that uses blockchain-resolved command-and-control.

The researchers also say the same exposed server contained Farsi-language artifacts and Israeli targeting data. In their view, that supports Iranian operational use, while Russian-language developer strings and CIS exclusions inside the malware point to a Russian-speaking developer or malware service provider.

That split is central to the report’s argument. JUMPSEC says MuddyWater operated the malware but did not author the entire platform. The group appears to have bought access to it, then deployed its own campaigns through the service with its own JWT credentials and targeting logic.

Where DinDoor fits in

Broadcom described DinDoor as a JavaScript-based backdoor delivered through signed MSI installers and linked the activity to Seedworm after U.S. and Israeli strikes on Iran. That report focused on the installer chain, the certificate overlap, and post-execution behavior.

JUMPSEC adds that DinDoor should not be treated as a purely MuddyWater-built tool. It says the Deno-based JavaScript malware sits inside a broader multi-tenant platform that other actors also use. In that model, MuddyWater becomes one operator among several, not the owner of the whole backend.

The report specifically points to serialmenot.com as shared infrastructure. JUMPSEC says the domain is not exclusive to MuddyWater and notes that other threat activity, including cybercriminal operations, used the same codebase with different campaign settings and credentials. That weakens any simple one-domain, one-actor attribution model.

What ChainShell changes

JUMPSEC says ChainShell is a separate malware component from the Deno-based DinDoor variants. It describes ChainShell as a thinner Node.js execution shell that receives JavaScript from the server, runs it with new Function(), and returns results back to the operator. The functionality lives mostly on the server side, which makes the agent itself less feature-heavy but still operationally useful.

That design changes how defenders should think about capability. A small agent on disk does not mean limited functionality. If the backend can push fresh logic on demand, operators can adapt tasks without replacing the implant every time.

JUMPSEC also says the malware excludes CIS locales and contains Russian-language strings such as “вернул” and “провайдер.” The report treats those as evidence of developer origin rather than operator identity, while the Farsi artifacts and Israeli targeting data support MuddyWater’s role as the end user.

Key findings at a glance

Item	What the reporting says
Threat actor using the platform	MuddyWater / Seedworm
Malware families discussed	DinDoor, ChainShell, CastleRAT-related builds
Core claim	MuddyWater used TAG-150 malware-as-a-service infrastructure rather than building all tooling itself
Attribution trail	Amy Cherne certificate, StageComp overlap, JWT campaign data, exposed C2 artifacts
Shared infrastructure	serialmenot.com appears multi-tenant, not exclusive to one actor
Main implication	State actors may increasingly buy criminal tooling instead of developing everything in-house

This summary reflects the attached text and the vendor reporting it references.

Why this matters for defenders

The report suggests attribution will get harder, not easier. If a victim network shows CastleRAT or ChainShell artifacts, the first impression may point to Russian cybercrime. JUMPSEC argues that deeper analysis can reveal a different operator sitting behind the same service infrastructure.

That creates a practical problem for incident response teams. If analysts separate “APT” and “cybercrime” too rigidly, they may miss hybrid operations where a state actor rents criminal tooling and runs espionage through a commercial malware platform.

Organizations in defense, aerospace, government, and energy should pay particular attention. Those sectors already sit inside MuddyWater’s historical targeting set, and JUMPSEC says the use of off-the-shelf criminal tooling gives the group faster access to newer capabilities without needing to build them internally.

FAQ