New DinDoor Backdoor Abuses Deno Runtime and MSI Installers to Evade Detection

A newly identified backdoor called DinDoor is using the legitimate Deno JavaScript runtime and MSI installer files to quietly slip past security defenses and compromise targeted systems.

The malware, tracked as a variant of the Tsundere Botnet, relies on trusted, signed runtime environments instead of deploying standard compiled implants.

This makes detection far more difficult in networks where tools like Deno are already allowlisted or not actively monitored.

DinDoor is delivered to victims through phishing emails or malicious drive-by downloads disguised as MSI files. Once a victim opens one, the installer downloads the Deno runtime from the official endpoint dl.deno[.]land without requiring administrator privileges.

The malware then runs obfuscated JavaScript to fingerprint the victim’s machine, reach its command-and-control (C2) infrastructure, and retrieve additional payloads.

Researchers at Hunt.io identified the malware while analyzing two samples uploaded to public repositories, revealing notable behavioral differences between the variants despite sharing the same execution model.

Their investigation found that a single HuntSQL query focused on DinDoor’s HTTP response returned 20 active C2 servers at the time of publication, spread across 15 different autonomous systems.

A recent Broadcom report also linked DinDoor activity to the Iranian APT group Seedworm, also tracked as MuddyWater, known to target organizations in the United States.

The malware’s connection to a wider threat cluster is particularly concerning. The C2 domain used in one sample, serialmenot[.]com, has been documented as shared, multi-tenant infrastructure used by ransomware operators, state-sponsored groups, and cybercrime actors.

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 confirms that multiple threat actors draw from the same shared platform using separate credentials.

Inside the Execution Chain

Understanding how DinDoor moves through a system reveals how deliberately it is built to avoid detection. When the first sample, migcredit.pdf.msi, executes, msiexec.exe drops a PowerShell script and launches it through cmd.exe with flags that hide the window, skip profile loading, and disable execution policy enforcement. 

The script checks whether deno.exe is already present and installs it if absent, then decodes a base64 string containing the JavaScript payload and uses Deno to execute it.

The second sample, Installer_v1.21.66.msi, takes a slightly different route. Built using the WiX toolset, it carries a code-signing certificate tied to “Amy Cherne,” which has appeared in prior research linked to MuddyWater.

Once launched, 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, so the code executes entirely in memory with nothing written 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. 

The Installer sample also embeds a hardcoded JSON Web Token in the C2 URL, exposing campaign metadata including domain and proxy settings.

Hunt.io’s query surfaced 20 active servers across multiple networks, several hosted on providers known for tolerating abuse.

Security teams should treat any unexpected deno.exe running as a child of powershell.exe or wscript.exe as a high-priority alert. Organizations should restrict MSI execution through AppLocker or Windows Defender Application Control to eliminate DinDoor’s primary delivery vector.

Monitoring for command-line patterns such as deno.exe -A data:application/javascript;base64 and TCP binds on localhost at ports 10044 or 10091 can help detect active infections.

Network defenders should review HTTP logs for Via: 1.1 Caddy headers on port 80 and consider blocking known associated domains and communications with suspect hosting providers.

Follow us on Google News, LinkedIn, and X to Get More Instant Updates, Set CSN as a Preferred Source in Google.