A sophisticated new backdoor malware, identified as DinDoor, is employing the legitimate Deno JavaScript runtime and Windows Installer (MSI) packages to evade detection and infiltrate targeted systems. This novel approach allows the malware to bypass traditional security measures by leveraging trusted execution environments. DinDoor’s emergence highlights an evolving threat landscape where attackers increasingly obfuscate their malicious activities within seemingly innocuous software components.
Researchers from Hunt.io have shed light on DinDoor’s operations, noting its similarity to variants of the Tsundere Botnet. Unlike many malware implants that are compiled directly, DinDoor relies on signed runtimes, making it significantly harder to flag as malicious, especially in networks where Deno might be an approved or monitored tool. This strategic use of legitimate software aims to blend seamlessly into network traffic and system processes.
Understanding the DinDoor Backdoor’s Execution Chain
The initial point of entry for DinDoor is typically through phishing emails or malicious drive-by downloads, often disguised as MSI files. Once a victim opens such a file, the installer initiates the download of the Deno runtime from an official source, dl.deno[.]land. Crucially, this download does not typically require administrator privileges, lowering the barrier for infection. Following the installation, the malware executes obfuscated JavaScript code. This code is designed to gather information about the victim’s machine, a process known as fingerprinting, and then establish communication with its command-and-control (C2) infrastructure to download further malicious payloads.
Hunt.io’s analysis revealed distinct behavioral differences between two examined DinDoor samples, despite their shared execution model. The first sample, named `migcredit.pdf.msi`, leverages `msiexec.exe` to drop and launch a PowerShell script. This script is executed with flags designed to conceal its activity, such as hiding the command window and bypassing execution policy restrictions. The script then checks for the presence of `deno.exe` and installs it if it’s not found. Subsequently, it decodes a Base64 encoded JavaScript payload and uses the Deno runtime to execute it.
The second sample, `Installer_v1.21.66.msi`, follows a slightly different path. Built using the WiX toolset, this MSI file carries a code-signing certificate linked to “Amy Cherne,” a name previously associated with the APT group Seedworm, also known as MuddyWater. Upon execution, this variant presents a fake Windows error dialog stating “Installation Failed! Ex00000185” to distract the user, while a VBScript launcher silently executes the PowerShell payload in the background. This sample passes its JavaScript payload directly to `deno.exe` as a URI argument, allowing the code to run entirely in memory without writing any files to disk, further enhancing its stealth capabilities.
Once the Deno runtime takes control, the DinDoor payload establishes a TCP listener on localhost. This listener acts as a mutex, preventing multiple instances of the malware from running concurrently on the same system. The malware then constructs a unique identifier for the infected machine by combining the user’s name, hostname, total memory, and the OS release string. This 16-character hexadecimal ID is appended to every communication request made to the C2 server, aiding in the tracking and management of compromised devices.
The `Installer_v1.21.66.msi` sample also embeds a hardcoded JSON Web Token within its C2 URL. This token contains campaign metadata, including domain and proxy server configurations. Hunt.io’s investigation identified 20 active C2 servers communicating with DinDoor samples at the time of their report. These servers were distributed across 15 different autonomous systems, with some hosted by providers known for their lax policies regarding malicious activity. This indicates a broad operational infrastructure designed to withstand takedown efforts.
An additional Broadcom report has linked DinDoor activity to the Iranian APT group Seedworm, also tracked as MuddyWater. This group is known for its targeting of organizations, particularly in the United States. The association with a well-established APT group raises concerns about the potential sophistication and strategic objectives behind DinDoor campaigns.
The malware’s connection to a wider threat cluster is further evidenced by the use of a shared C2 domain, `serialmenot[.]com`. This domain has been previously documented as multi-tenant infrastructure used by a variety of threat actors, including ransomware operators, state-sponsored groups, and cybercrime syndicates. Research by JUMPSEC has linked this domain to TAG-150, which utilizes it as the backend for a malware family known as CastleLoader. Significant behavioral overlaps have been observed between DinDoor and CastleLoader, confirming that multiple threat actors are leveraging the same shared infrastructure for their operations, albeit with separate credentials and distinct malware families.
Mitigation and Detection Strategies for DinDoor
Security teams are advised to treat any instance of `deno.exe` running as a child process of `powershell.exe` or `wscript.exe` as a high-priority alert. Such process lineage is a strong indicator of potential DinDoor activity. Organizations should implement strict application control policies, such as AppLocker or Windows Defender Application Control, to restrict the execution of MSI installers. This is a crucial step in eliminating DinDoor’s primary delivery vector.
Network defenders can enhance detection capabilities by monitoring for specific command-line patterns associated with DinDoor. These include patterns like `deno.exe -A data:application/javascript;base64`. Additionally, monitoring for unexpected TCP binds on localhost at ports 10044 or 10091 can help identify active infections. Reviewing HTTP logs for the presence of `Via: 1.1 Caddy` headers on port 80 might also provide clues to active DinDoor communications, as Caddy is often used as a reverse proxy in such campaigns.
Considering the collaborative nature of threat actors and the use of shared infrastructure, it is also prudent to block known associated malicious domains and communications directed towards suspect hosting providers. Information sharing between security researchers and organizations is vital for staying ahead of these evolving threats. Continuous monitoring and a proactive security posture are essential for defending against sophisticated malware like DinDoor.