DinDoor Backdoor Exploits Deno Runtime and MSI Installers to Evade Detection
A newly identified backdoor, dubbed DinDoor, is leveraging the legitimate Deno JavaScript runtime and MSI installer files to infiltrate systems stealthily. This sophisticated malware, associated with the Tsundere Botnet, utilizes trusted runtime environments instead of traditional compiled implants, significantly complicating detection efforts, especially in networks where tools like Deno are already approved or not closely monitored.
Delivery Mechanism and Execution Chain
DinDoor is disseminated through phishing emails or malicious drive-by downloads masquerading as MSI files. Upon execution, these installers download the Deno runtime from its official source, dl.deno[.]land, without necessitating administrative privileges. Subsequently, the malware executes obfuscated JavaScript to fingerprint the victim’s machine, establish communication with its command-and-control (C2) infrastructure, and retrieve additional payloads.
Researchers at Hunt.io identified DinDoor while analyzing two samples uploaded to public repositories, revealing notable behavioral differences between the variants despite sharing the same execution model. Their investigation uncovered 20 active C2 servers associated with DinDoor, distributed across 15 different autonomous systems. A recent Broadcom report also linked DinDoor activity to the Iranian APT group Seedworm, also known as MuddyWater, which has a history of targeting organizations in the United States.
Connection to Shared Malicious Infrastructure
The malware’s association with a broader threat cluster is particularly concerning. One of the C2 domains used by DinDoor, serialmenot[.]com, has been documented as shared, multi-tenant infrastructure utilized by ransomware operators, state-sponsored groups, and cybercriminals. Research by JUMPSEC tied this domain to TAG-150, which uses it as the backend for a malware family called CastleLoader, with which DinDoor shares behavioral overlaps. This indicates that multiple threat actors are drawing from the same shared platform using separate credentials.
Detailed Execution Process
Understanding DinDoor’s execution process sheds light on its stealthy nature. In one observed sample, migcredit.pdf.msi, the execution begins with msiexec.exe dropping a PowerShell script and launching it through cmd.exe with flags that hide the window, skip profile loading, and disable execution policy enforcement. The script checks for the presence of deno.exe and installs it if absent, then decodes a base64 string containing the JavaScript payload and uses Deno to execute it.
Another sample, Installer_v1.21.66.msi, follows a slightly different path. Built using the WiX toolset, it carries a code-signing certificate tied to Amy Cherne, which has appeared in prior research linked to MuddyWater. Upon execution, it displays a fake Windows error dialog reading Installation Failed! Ex00000185 while a VBScript launcher silently runs the PowerShell payload in the background. This variant passes its JavaScript directly to deno.exe as a URI argument, allowing the code to execute entirely in memory without writing to disk.
Once Deno takes over, the payload binds a TCP listener on localhost as a mutex to prevent re-infection. It builds a unique fingerprint from the victim’s username, hostname, total memory, and OS release string, producing a 16-character hex ID appended to every C2 request.
Implications and Recommendations
The use of legitimate tools like Deno in malicious campaigns underscores the evolving tactics of threat actors aiming to evade detection. Organizations should exercise caution when handling MSI files from untrusted sources and monitor for unusual network activity associated with Deno runtime executions. Implementing robust email filtering, user education on phishing tactics, and endpoint detection and response solutions can help mitigate the risks posed by such sophisticated malware.
