A Windows sandbox may show one graphics-adapter query and nothing else. On a workstation that looks real, the same malware continues into registry persistence and command communications through a signed developer runtime.
Binary Defense identified Dindoor at U.S. software and banking companies and a Canadian nonprofit while tracking the backdoor in early 2026. The researchers link the activity to the Iranian group MuddyWater, although their report does not publish a victim count or a complete set of campaign infrastructure.
Deno carries three encoded stages
Dindoor appears after initial staging in spearphishing intrusions. The source does not describe it as the initial-access file. Its loader first checks for Deno, a legitimate JavaScript and TypeScript runtime. If the runtime is absent, the loader uses curl.exe to download it from deno.land.
Deno then receives a long base64-encoded argument containing the backdoor’s first stage. That script fingerprints the host, establishes command communications with a remote server, and compiles and executes a second payload. The second stage immediately fetches and executes a third. The final stage performs the persistence and listener behavior that defenders can recognize.
This separation matters during triage. A downloaded Deno runtime is a staged component. It does not establish that every later payload executed. A running deno.exe with an unusually long encoded argument, followed by the later process and registry events, provides much stronger evidence of the chain.
Binary Defense puts the design plainly: “Using a signed, mainstream developer tool as its execution engine is the detail that sets Dindoor apart.” Deno is being abused rather than exploited. The source identifies no vulnerable Deno release, fixed version, or build that administrators can patch to remove this behavior.
Figure details
A layered flow begins with later-stage spearphishing delivery. The loader checks for Deno and uses curl to retrieve the legitimate runtime when needed. Deno executes a base64-encoded first stage, which fingerprints the host and retrieves two later stages. The final layer first queries Win32_VideoController. A machine that passes the environment check receives Run-key persistence through wscript and an AppData Local VBScript, followed by a Deno TCP listener. A sandbox may stop at the video-controller query and expose none of the persistence behavior.
The sandbox check hides persistence
Before persisting, the final stage launches this query through cmd.exe and PowerShell:
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 result exposes graphics-adapter names associated with VMware, VirtualBox, QXL, or Hyper-V. When Dindoor decides that the host is an analysis environment, the chain can stop there. That ordering creates a useful false-negative trap: a sandbox report containing only the WMI query has not reproduced the behavior seen on a target workstation.
On a host that passes the check, the sample creates Run-key persistence with this value:
wscript.exe "C:\Users\Admin\AppData\Local\Serial\Lynx_system59.vbs"The username is sample-specific. The durable pattern is wscript.exe launching a VBScript from a subdirectory below AppData\Local. Dindoor then uses Deno’s listen function to create a TCP listener. Its command traffic is also base64-encoded.
The report names no campaign domain, IP address, file hash, registry value name, or fixed port. It also does not report a response from Deno, Microsoft, or the affected organizations. Defenders should preserve those gaps instead of filling them with indicators from unrelated MuddyWater activity.
Hunt the four-signal sequence
Start with process telemetry for deno.exe carrying an unusually long base64 argument on Windows systems without a developer profile. Correlate that execution with curl.exe reaching deno.land, a legitimate shared service that the malware abuses to obtain the runtime.
Next, look for cmd.exe spawning PowerShell to query Win32_VideoController. Search registry-change telemetry for a Run key that invokes wscript.exe against a .vbs file below AppData\Local. Treat the query as an early lead and the combined process-plus-registry sequence as the stronger finding.
Verify the hunt against a known Deno development host and a representative non-development Windows endpoint. The expected result is that legitimate systems may reach deno.land or run deno.exe, but they do not produce the full sequence of a long encoded Deno argument, the video-controller query, and Run-key persistence through an AppData VBScript. If the full sequence appears, isolate the endpoint, preserve process, registry, script, and network evidence, and determine which downloaded stages actually ran.
Signed tooling changes the shape of trust, not the need for evidence. Dindoor is detectable because its environment check, execution chain, and persistence relationship remain recognizable after the encoded payload changes. A hunt built around those relationships survives the next sample better than a signature tied to the one already found.