DinDoor Backdoor Abuses Deno Runtime and MSI Installers for Evasion

Key Takeaways

• A new backdoor, DinDoor, is actively being deployed, leveraging the legitimate Deno JavaScript runtime and Microsoft Installer (MSI) files to bypass traditional security defenses.
• DinDoor is delivered via phishing emails or malicious drive-by downloads disguised as MSI files, with execution chains designed for stealth and persistence.
• The malware is linked to the Iranian APT group Seedworm (MuddyWater) and utilizes shared command-and-control (C2) infrastructure, indicating its use by multiple sophisticated threat actors.
• Organizations should implement strict application control policies, monitor for suspicious Deno and PowerShell activity, and block known malicious indicators to mitigate risk.

A sophisticated new backdoor, dubbed DinDoor, is currently being utilized by threat actors, employing a stealthy combination of the legitimate Deno JavaScript runtime and Microsoft Installer (MSI) files to evade detection and compromise systems. This innovative approach allows the malware to integrate into environments where Deno might be an approved application, making traditional security measures less effective. For a comprehensive breakdown of its evasion tactics, a detailed analysis is available from Hunt.io researchers.

Identified as a variant of the Tsundere Botnet, DinDoor distinguishes itself by relying on trusted, signed runtime environments instead of conventional compiled malware implants. This strategy significantly complicates detection efforts, particularly within networks where tools like Deno are either explicitly allowlisted or not subject to rigorous monitoring.

Infection Vector and Initial Execution

Victims are typically infected with DinDoor through carefully crafted phishing emails or insidious drive-by downloads presented as benign MSI files. Upon execution of a malicious MSI, the installer initiates the download of the Deno runtime directly from its official endpoint, dl.deno[.]land, critically, without requiring elevated administrator privileges.

Following Deno’s installation, the backdoor proceeds to execute obfuscated JavaScript. This script performs initial reconnaissance of the compromised machine, establishes communication with its command-and-control (C2) infrastructure, and subsequently retrieves additional malicious payloads. Researchers at Hunt.io discovered this malware during their analysis of two samples submitted to public repositories, noting distinct behavioral patterns despite their shared execution methodology.

Command and Control Infrastructure

The Hunt.io investigation, using a targeted HuntSQL query, revealed 20 active C2 servers associated with DinDoor at the time of their report. These servers were distributed across 15 different autonomous systems, highlighting the distributed and resilient nature of the threat actor’s infrastructure. Furthermore, a recent report from Broadcom has directly linked DinDoor activities to Seedworm, also known as MuddyWater, an Iranian Advanced Persistent Threat (APT) group known for targeting organizations within the United States.

A concerning aspect of DinDoor is its connection to a broader threat ecosystem. One of the C2 domains identified, serialmenot[.]com, has been previously documented as shared, multi-tenant infrastructure. This platform is known to be utilized by various malicious entities, including ransomware operators, state-sponsored groups, and other cybercrime actors. JUMPSEC’s research further corroborated this, linking the serialmenot[.]com domain to TAG-150, which uses it as the backend for a malware family named CastleLoader. DinDoor exhibits behavioral similarities with CastleLoader, suggesting that multiple threat actors are leveraging the same shared platform, albeit with separate credentials.

Inside the Execution Chain

A closer examination of DinDoor’s execution flow underscores the deliberate design choices made to ensure stealth and evade detection.

Sample 1: migcredit.pdf.msi

When the first sample, identified as migcredit.pdf.msi, is executed, msiexec.exe drops a PowerShell script. This script is then launched via cmd.exe, utilizing specific flags to hide the command window, bypass profile loading, and disable execution policy enforcement. The PowerShell script first verifies the presence of deno.exe on the system. If Deno is not found, the script proceeds to install it. Subsequently, it decodes a base64-encoded JavaScript payload and uses Deno to execute this malicious code.

Sample 2: Installer_v1.21.66.msi

The second sample, Installer_v1.21.66.msi, employs a slightly different, yet equally deceptive, execution path. Developed using the WiX toolset, this variant carries a code-signing certificate issued to “Amy Cherne,” a name previously associated with MuddyWater in other security research. Upon launch, the installer displays a deceptive Windows error message stating “Installation Failed! Ex00000185.” Concurrently, a VBScript launcher silently executes the PowerShell payload in the background. Notably, this variant passes its JavaScript payload directly to deno.exe as a URI argument, enabling the code to execute entirely in memory without writing any artifacts to disk, further enhancing its stealth capabilities.

Once Deno takes control, the payload binds a TCP listener on localhost, serving as a mutex to prevent re-infection of the same system. It then generates a unique fingerprint for the victim’s machine by combining the username, hostname, total memory, and OS release string. This process yields a 16-character hexadecimal ID, which is appended to every subsequent C2 request. The Installer sample also embeds a hardcoded JSON Web Token within the C2 URL, which inadvertently exposes campaign metadata such as domain and proxy settings. Hunt.io’s analysis confirmed 20 active servers across various networks, with several hosted by providers known for their lax enforcement against abuse.

What You Should Do

• Implement Application Control: Utilize AppLocker or Windows Defender Application Control to restrict MSI file execution, thereby eliminating a primary delivery vector for DinDoor.
• Monitor Deno and PowerShell Activity: Treat any unexpected instances of deno.exe running as a child process of powershell.exe or wscript.exe as a critical alert.
• Detect Command-Line Patterns: Monitor for specific command-line patterns, such as deno.exe -A data:application/javascript;base64, which indicate malicious Deno usage.
• Monitor for TCP Binds: Watch for TCP listener binds on localhost at ports 10044 or 10091, as these are indicators of an active DinDoor infection.
• Review HTTP Logs: Examine HTTP logs for the presence of Via: 1.1 Caddy headers on port 80, which can signal C2 communication.
• Block Known Indicators: Proactively block known associated domains and IP addresses, and consider restricting communications with suspect hosting providers identified in threat intelligence reports.

Disclaimer: HackersRadar reports on cybersecurity threats and incidents for informational and awareness purposes only. We do not engage in hacking activities, data exfiltration, or the hosting or distribution of stolen or leaked information. All content is based on publicly available sources.