An Iranian-associated threat actor has been discovered using a legitimate developer runtime to conceal its Dindoor backdoor in Windows environments, complicating detection and response efforts. The malware is deployed once phishing attacks deliver a loader to the target device, after which it uses Deno—a signed runtime for JavaScript and TypeScript—to run the payload in an obfuscated manner. The code is delivered via a large Base64-encoded command, enabling the threat to blend into expected software activity. Vulnerable sectors include U.S. software and banking organizations, as well as a Canadian non-profit.
How the Attack Works
Binary Defense started tracking this campaign in early 2026 and attributed it to the Iranian threat group MuddyWater. The intrusions typically begin with a phishing stage that installs a loader. If Deno isn’t already present, the malware fetches it using curl and then executes the Dindoor code encoded in Base64. This misuse of a trusted, signed runtime helps the threat evade basic scrutiny.
The campaign’s execution is multi-staged. An initial script collects system information and establishes communication with a remote server. Subsequent payloads are then installed in layers. Before triggering its final, most damaging functionality, the backdoor checks whether the environment is being monitored or emulated—testing for graphics adapters tied to VMware, VirtualBox, Hyper-V or other tools often used in malware analysis. If a virtualization environment is detected, the malware halts further operations to avoid exposure.
Only after this stage does the threat establish persistence by creating a registry Run key to launch a VBScript through wscript at user login. This stealthy chain—signed runtime, encoded scripts, environment checks, delayed persistence—is designed to reduce forensic visibility and detection.
Detection and Mitigation Strategies
Because Dindoor leverages trusted components (like Deno, signed utilities, PowerShell) and encodes much of its behavior, conventional antivirus signature-based detection often fails. Analysts recommend security teams hunt for suspect behaviors such as unusually long Base64 arguments passed to Deno, use of curl to download runtimes where none were expected, and registry entries pointing to VBScript under user profiles. Also flagged are graphics-adapter queries used to detect virtual machines, especially when they precede attempts to persist.
Combatting this threat effectively requires tighter controls on software installation and script execution. Organizations should monitor developer tool use, restrict unapproved runtime downloads, and integrate phishing reports with endpoint process and registry monitoring. Ensuring that VBScript, PowerShell, and signed runtimes are only used in sanctioned ways can reduce exposure significantly.
While none of the techniques MuddyWater uses are entirely new on their own, the way they are combined elevates the challenge to security teams. Trusted tools, encoding, environment checks, and delayed persistence together help evade detection and prolong access on victim systems.
What this means: The use of legitimate developer tools like Deno isn’t just a curiosity—it’s a sign that attackers are shifting tactics to exploit trust. As defense strategies relying on static signatures become increasingly inadequate, detection systems must adapt to recognize behavior patterns and context. Watch for unusual runtime launches, unexpected scripting in user contexts, and registry keys that activate persistence. As MuddyWater refines this playbook, security operations centers will need threat intelligence and telemetry that go beyond traditional indicators.
