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. 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. 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. 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. 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.
