Dindoor - The Technical Analysis of an Iranian Backdoor

Dindoor is a backdoor that abuses the Deno runtime to execute malware within a target environment. Rather than shipping its own interpreter, Dindoor relies on Deno, a legitimate and widely used JavaScript and TypeScript runtime, and will install that runtime on the victim machine on demand if it is not already present. Using a signed, mainstream developer tool as its execution engine is the detail that sets Dindoor apart.

Binary Defense's Threat Research team began tracking Dindoor in early 2026 after identifying it at U.S. software and banking companies and a Canadian non-profit. The backdoor has been linked to the Iranian APT group MuddyWater. Few of its individual components are novel; what makes Dindoor effective is the combination of a signed third-party runtime performing execution, base64 encoding at every stage, and an environment check that must pass before the backdoor establishes persistence.

Getting to Dindoor

Dindoor has been observed primarily as a later-stage payload in a spearphishing attack rather than as the initial access vector. After initial staging, the loader confirms whether the Deno runtime is present on the victim machine and, if it is not, downloads it from deno.land via curl.exe. Deno is then launched and provided a base64-encoded string that comprises the Dindoor backdoor itself, a pattern seen consistently across every payload associated with Dindoor.

From there, the attack chain runs three stages deep:

1. The initial script develops a fingerprint of the host and establishes command and control communications with a remote server before compiling and executing a secondary payload.
2. The secondary payload immediately fetches and executes a third-stage payload from the C2 server.
3. The final payload is responsible for the malicious behavior described below.

The sandbox check runs first

Before proceeding, the final payload executes the following command to determine whether it is being detonated within a virtual machine, an automated sandbox, or a low-interaction analysis environment:

C:\Windows\system32\cmd.exe /d /s /c "powershell -Command "Get-WmiObject -Class Win32_VideoController | Select-Object -Property Name | Format-List -Property Name | Out-String""

The query returns the name of the system's graphics adapter, which serves as a reliable indicator of virtualization. VMware SVGA, VirtualBox, QXL, and Hyper-V synthetic display adapters each identify themselves by name, allowing Dindoor to distinguish an analysis environment from a genuine target before taking any further action.

Persistence, but only on a real machine

If the device is determined not to be an analysis machine, persistence is established by creating a Run registry key containing the following string:

wscript.exe "C:\Users\Admin\AppData\Local\Serial\Lynx_system59.vbs"

The ordering is as notable as the technique itself. Because persistence is gated behind the environment check, a sample detonated in a sandbox produces only the single PowerShell WMI query and nothing further. The behavior that matters never executes, which is precisely the intent.

Command and control through a Deno listener

Command and control communications are established via Deno's listen function to create a TCP listener. As with every other component of the attack chain, this traffic is base64-encoded to obfuscate its contents.

Why a signature gets you one sample

Every stage of Dindoor's execution relies on encoded payloads and legitimate tooling. curl.exe, deno.exe, wscript.exe, and powershell.exe perform the actual work, and each is a signed binary expected on a normal Windows host. This is precisely why signature-based detection alone falls short. A hash or static string will identify a sample already in hand, but the next build, with freshly encoded payloads, will pass unnoticed.

What does not change between builds is the behavior beneath the encoding, and that is where detection must focus:

• deno.exe launching with a lengthy base64 argument on a host with no developer profile
• curl.exe reaching out to deno.land on a machine with no legitimate reason to install a JavaScript runtime
• a Run key directing wscript.exe to a VBScript within a subdirectory of AppData\Local
• a `Win32_VideoController` WMI query originating from a PowerShell process spawned by cmd.exe

Binary Defense researchers developed hypothesis-based threat hunting queries around these patterns, targeting the fixed structure of Dindoor's execution chain rather than the encoded contents that change with each build. 

What this says about MuddyWater

Individually, none of these techniques are new. Run key persistence, virtual-machine checks, base64 layering, and multi-stage delivery have all been part of the toolkit for years. Dindoor's evolution is in the delivery vehicle. By adopting a mainstream developer runtime as its execution engine, MuddyWater gains a legitimate signed binary, a network destination few organizations have reason to block, and a script format that most detection content was never written to address.

As MuddyWater continues to refine its tradecraft and broaden its targeting, we expect this approach to be adopted more widely, both by the group and by others studying its work.

Binary Defense's Threat Research team develops and refines behavioral detections and hunting queries against tradecraft like this, then applies them within our own SOC. Threat Hunting is included with Binary Defense MDR.