DinDoor Backdoor Exploits Deno and MSI Installers to Slip Past Detection

DinDoor is a newly documented backdoor that abuses the Deno JavaScript runtime and MSI installer files to execute attacker‑controlled code while sidestepping traditional detection controls quietly.

Hiding behind trusted runtimes and common Windows tooling gives threat actors a flexible way to deploy fileless or low‑footprint malware into enterprise environments.

Instead of shipping a conventional compiled implant, DinDoor delivers obfuscated JavaScript that runs under Deno, a legitimate, signed runtime that many organizations allowlist for developer use.

This shift creates a blind spot in environments tuned heavily for PowerShell, Python, or Node.js activity but lacking visibility into Deno‑based execution.

DinDoor was first publicly named in March 2026 and is tracked as a variant of the Tsundere botnet, a JavaScript remote access tool that historically relied on Node.js for execution.

Multiple vendors and independent researchers have linked recent DinDoor campaigns to the Iranian APT group Seedworm (also known as MuddyWater), which has been targeting U.S. and other global organizations with phishing and collaboration‑platform lures.

The same ecosystem of infrastructure and tooling overlaps with a broader malware‑as‑a‑service platform that includes CastleLoader/CastleRAT, giving operators a shared, multi‑tenant backend.

Delivery via MSI and Deno

DinDoor arrives primarily through malicious MSI installers delivered via phishing emails, drive‑by downloads, or messaging‑platform social engineering, often masquerading as documents or business software.

Upon execution, msiexec.exe drops Juliet_widget15.ps1 to AppDataLocaldocuments and launches it via cmd.exe with flags to hide any visible window, skip profile loading, and disable execution policy enforcement.

When executed, the MSI uses msiexec.exe to stage intermediate scripts (PowerShell and/or VBScript) that handle the rest of the infection chain.

These scripts first check whether Deno is present in the user profile directory and, if missing, silently download it from the legitimate dl.deno[.]land endpoint without requiring administrative privileges.

In one observed variant, the PowerShell script writes a base64‑decoded JavaScript payload to disk before invoking it with deno.exe, while another variant passes a data:application/javascript;base64, URI directly to Deno so the payload executes purely in memory.

This in‑memory option leaves no script file on disk, sharply reducing forensic artifacts and bypassing many file‑centric antivirus detections.

Once deno.exe takes over, DinDoor first binds a TCP listener on localhost, using fixed ports such as 10044 or 10091, and exits if the port is already in use, effectively acting as a simple mutex to prevent multiple infections on the same host.

The malware then fingerprints the victim by hashing together properties like username, hostname, total RAM, and OS release into a unique 16‑character hexadecimal identifier that is attached to every command‑and‑control (C2) request.

DinDoor probes its C2 by sending a short‑timeout GET request to a /health endpoint, expecting an HTTP 200 with body “ok” before proceeding to the next stage.

In one MSI sample, the C2 URL path embeds a hard‑coded JSON Web Token (JWT) segment (for example, /mv2//), which discloses campaign metadata and ties activity back to the shared domain serialmenot[.]com, previously associated with both state‑sponsored and criminal operators.

Other variants use alternative paths like /event and heavier JavaScript obfuscation, but maintain the same core fingerprinting and beacon logic.

Infrastructure and Detection Opportunities

Hunt.io researchers showed that DinDoor HTTP responses are consistent enough to use as a pivot for infrastructure discovery, particularly through servers on port 80 returning 404 Not Found with Content‑Length: 13 and headers including Via: 1.1 Caddy, 1.1 Caddy and X‑Request‑Id.

A single HuntSQL query built on these traits surfaced around 20 active DinDoor servers across roughly 15 autonomous systems, many on hosting providers known for slow abuse handling or “bulletproof” services.

Additional confirmation is possible by querying the /health endpoint and checking for the ok response, while keeping in mind that changes in behavior may reflect dormant or reconfigured infrastructure.

From a defense perspective, DinDoor’s chain provides multiple choke points: tightening MSI execution via AppLocker or WDAC, monitoring for unexpected deno.exe processes spawned by PowerShell or wscript, and alerting on Deno command lines that execute base64 JavaScript directly from a data: URI.

Network teams should also review logs for the distinctive Caddy headers, unexpected traffic to serialmenot[.]com or related hosting providers, and anomalies tied to Deno‑initiated outbound connections.

IOCs

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