Deno Runtime Malware: Inside the CastleRAT Fileless Attack Chain

Cybersecurity researchers at ThreatDown, the corporate security division of Malwarebytes, published findings on March 10, 2026, describing what they characterize as a first-of-its-kind attack chain: one that co-opts Deno, a legitimate, code-signed JavaScript runtime used widely in software development, to serve as the execution engine for fileless malware delivery. The payload at the end of that chain is CastleRAT, a remote access trojan used in credential theft, capable of collecting system information and enabling remote access for data exfiltration.

The research was authored by Lorenzo Corazzi, Malware Research Engineer at ThreatDown, and uncovered during an active incident investigation by the company's Endpoint Detection and Response (EDR) team. What makes this campaign technically significant is not any single technique taken in isolation — each element has appeared in prior threats — but rather the combination and sequencing of those elements, and specifically the choice of Deno as the trusted process within which malicious code runs.

What Is Deno, and Why Does It Matter Here

Deno is a JavaScript and TypeScript runtime built on the V8 engine and written in Rust. Released publicly in 2020 by Ryan Dahl, the original creator of Node.js, Deno was designed specifically to address security shortcomings in Node.js. Its architecture includes a strict permission system, Rust's memory safety guarantees, and native support for TypeScript. Enterprises and developers use it for server-side scripting, automation, and lightweight microservices.

Because Deno is code-signed software distributed through official channels and widely recognized by operating systems and security tools as a legitimate developer application, it holds a degree of inherent trust that traditional malware binaries do not. When Deno executes code on a Windows endpoint, traditional antivirus systems that rely primarily on disk-based file scanning may fail to detect this activity — particularly those focused on detecting malicious files written to disk rather than anomalous process behavior at runtime.

This abuse represents an evolution beyond conventional living-off-the-land (LOTL) attacks, which traditionally rely on tools already built into the operating system — PowerShell, mshta.exe, wmic.exe, cmd.exe, and similar Windows-native binaries. By extending that technique to a third-party developer runtime, attackers add another layer to the trusted-process problem that defenders already struggle to contain.

The Three-Phase Attack Chain

ThreatDown's published research details a multi-phase infection sequence designed at each stage to remain invisible to conventional antivirus tools. The chain proceeds across three distinct phases, each handing execution to the next while progressively loading more destructive capability.

Phase One: ClickFix Social Engineering

The infection begins not with a software exploit but with social engineering. The attacker presents the target with a ClickFix lure — a fake browser error message or CAPTCHA verification prompt rendered on a malicious or compromised webpage. The page instructs the user to copy a command to their clipboard, then open the Windows Run dialog and paste it manually.

This mechanism is particularly effective at bypassing web-layer security controls because the user themselves becomes the execution vector. No browser exploit is needed; no file is downloaded by the browser. The user's own action introduces the malicious command to the system. ClickFix has grown into one of the most consistently abused social engineering techniques in 2025 and into 2026, with campaigns distributing StealC, LummaC2, and now CastleRAT through this pathway.

# Example ClickFix lure command structure (illustrative, not exact IOC)
# User is instructed to open Run (Win+R) and paste:
powershell -WindowStyle Hidden -EncodedCommand [base64_payload]

# This triggers the loader chain silently in the background
# while the user believes they completed a browser verification step

Phase Two: Silent Deno Installation and Obfuscated Script Execution

The command pasted by the user silently downloads and installs the Deno runtime onto the target machine. Once installed, Deno is invoked to execute heavily obfuscated JavaScript. Because the code now runs inside a process the operating system recognizes and trusts — a digitally signed, legitimate developer tool — it inherits the execution privileges of that trusted process and evades behavioral alarms designed to flag anomalous binaries.

This is the architectural novelty of the campaign. Rather than attempting to disguise malicious code as a system binary, or trying to evade detection through packing or polymorphism, the attackers simply run their code inside legitimate software. The malicious logic is not masquerading as Deno; it is genuinely executing inside Deno. Security tools that focus primarily on detecting malicious files written to disk have no file to scan.

The Deno JavaScript stage does not directly load the final payload. Instead, its role is to act as a trusted launcher for the next layer: it downloads a portable Python environment that has been renamed Petuhon — a name crafted to mimic a legitimate system component — along with the steganographic payload carrier described below. This layered handoff is deliberate: Deno earns the initial process trust, and then passes execution to Python while remaining the parent process in the chain.

Phase Three: Steganography, PyArmor Obfuscation, and Reflective PE Loading

The Deno script retrieves the final payload carrier, but not in any format a security tool would conventionally recognize as malware. The CastleRAT executable is encrypted and hidden inside a JPEG image file — named CFBAT.jpg — using steganography. A highly obfuscated Python script, protected by PyArmor (a commercial code protection tool commonly used by software developers), reads the image, decodes it, and injects the malware directly into system memory using a technique called reflective PE loading.

PyArmor's presence matters here. It is a legitimate Python obfuscation product, not malware tooling. Using it to protect the injection script adds another layer of signed, legitimate software to the chain — PyArmor-protected scripts are not inherently suspicious — while rendering the malicious logic effectively unreadable without dynamic analysis. The choice signals that the attackers understand not just how to evade antivirus, but how to weaponize the entire ecosystem of legitimate developer tools.

Reflective PE loading allows a Windows executable (PE file) to load itself into memory without touching the file system. The payload is decompressed, its memory sections are mapped, relocations are applied, and execution is redirected — all within RAM. The hard drive is never written. Traditional antivirus engines, which work by scanning files on disk against known malware signatures, have nothing to scan.

CastleRAT: Capabilities Once Established in Memory

Once reflectively loaded into system memory, CastleRAT operates as a full-featured remote access trojan. ThreatDown's analysis documents its capabilities across several categories of post-exploitation activity:

• Host fingerprinting and C2 beaconing: Before executing any destructive function, CastleRAT gathers the computer name, username, machine GUID, Windows product name, and public IP address (via services like ip-api.com), sending this telemetry to its C2 server. ThreatDown identified command-and-control infrastructure used by the attackers to receive host telemetry and manage infected systems.
• Keylogging via Windows API hooks: CastleRAT captures every keystroke using the SetWindowsHookEx() API, which installs a system-wide hook into the OS's input processing pipeline. Keystrokes are captured through Windows API hooks and stored locally before exfiltration, according to the ThreatDown analysis.
• Clipboard hijacking and crypto address substitution: Dedicated monitoring threads continuously read the clipboard. When the malware detects a copied cryptocurrency wallet address, it silently replaces it with an attacker-controlled address before paste occurs, using the SendInput() API to simulate the substitution invisibly. Harvested data can also be exfiltrated directly via this channel.
• Digital identity and session token theft: CastleRAT actively targets browser cookies, saved credentials, browsing history, and browser extension data — including data associated with cryptocurrency wallets. It further targets session tokens for Telegram Desktop and Discord, as well as SSH keys stored on the endpoint. This means a single successful infection can compromise access to developer infrastructure, cloud services, and communication platforms simultaneously.
• Audio and video surveillance: CastleRAT can covertly enumerate and initialize the victim's webcam and microphone using the Windows Media Foundation API, including the MFEnumDeviceSources() call, for real-time monitoring with no user-visible indicator that capture is active.
• Invisible backdoor with persistence: The malware establishes anonymous IPC pipe communications granting attackers full remote shell access with no visible console window. To survive system reboots, CastleRAT silently registers a Scheduled Task via PowerShell — in the ThreatDown investigation, they found that misleading task names such as VirtualSmokestGuy666 were revealed — that points back to the obfuscated Python loader, restarting the in-memory execution loop automatically after every reboot.
• Command-and-control evasion via dead-drop resolvers: Prior malware campaigns have used public web content as “dead-drop resolvers,” though this technique was not confirmed in the ThreatDown-documented Deno campaign — a technique in which C2 domains or IP addresses are encoded inside publicly accessible, legitimate web content, making C2 traffic difficult to distinguish from normal browsing activity. The Velvet Tempest campaign used dedicated C2 domains including nachalonachalo[.]com and akamedmain[.]com alongside this technique.

The CastleRAT trojan is not new to the threat landscape. It has appeared in campaigns associated with the CastleLoader malware-as-a-service ecosystem, which has historically distributed multiple RAT families and information stealers. A February 2026 Bitdefender report documented a significant surge in LummaStealer infections being delivered through CastleLoader between December 2025 and January 2026, with campaigns leveraging ClickFix as the initial-access mechanism. Bitdefender's researchers described CastleLoader's modular in-memory execution model, extensive obfuscation, and flexible C2 communication design as making it well-suited for large-scale malware distribution — and identified its payload roster as spanning Stealc, RedLine, Rhadamanthys, MonsterV2, CastleRAT, SectopRAT, NetSupport RAT, and WarmCookie. What is new in the ThreatDown-documented campaign is the delivery mechanism — the use of Deno as the initial execution environment — combined with the steganographic JPEG carrier and the PyArmor-protected Python injection stage for the final payload.

CastleRAT in the Broader Threat Ecosystem

The ThreatDown campaign does not exist in isolation. In the weeks before this disclosure, separate research by MalBeacon documented Velvet Tempest (also tracked as DEV-0504) using ClickFix and CastleRAT in a different attack chain — one that does not use Deno but that illuminates the broader operational adoption of this malware family.

Velvet Tempest is a ransomware affiliate group with a documented history spanning at least five years and associations with Ryuk, REvil, Conti, BlackCat/ALPHV, LockBit, and RansomHub. MalBeacon's research captured a 12-day intrusion operation observed between February 3 and 16, 2026, against an emulated U.S. non-profit organization. The intrusion began with a ClickFix lure at a fake CAPTCHA page, which triggered nested cmd.exe chains. The attacker used finger.exe — a legitimate but rarely invoked Windows utility communicating over TCP port 79 — to retrieve initial loaders. Subsequent stages pulled DonutLoader from attacker-controlled domains using curl.exe, compiled .NET components on-host via csc.exe, and deployed CastleRAT under C:\ProgramData\AndronFolder\.

MalBeacon stated in its February 26, 2026 operation report that this constituted, to their knowledge, the first public documentation tying ClickFix-style malvertising chains to Velvet Tempest — marking both a new actor attribution and a new initial-access technique for a group that had previously relied on different delivery methods. (Source: MalBeacon / Deception.Pro, February 26, 2026)

CastleRAT's C2 infrastructure in that campaign used Steam Community profile pages as dead-drop resolvers alongside dedicated C2 domains. Active Directory enumeration, domain trust discovery, and Chrome credential extraction followed within minutes of the initial access. The full observed duration was 12 days, 20 hours, and 15 minutes. Velvet Tempest is associated with Termite ransomware operations, though Termite itself was not deployed during MalBeacon's observed window.

What the parallel campaigns reveal is that CastleRAT is being adopted across distinct threat actor groups, and that the ClickFix initial-access technique continues to serve as a reliable delivery mechanism regardless of the final payload. The innovation documented by ThreatDown is the substitution of Deno for PowerShell or mshta.exe as the trusted execution environment — a substitution that likely emerged precisely because security tooling has grown better at flagging anomalous behavior from those more commonly abused system tools. Now that Deno is a proven evasion vehicle — Deno has also been observed in separate research involving the MuddyWater threat group’s Dindoor backdoor, indicating that multiple actors are experimenting with developer runtimes as execution environments — it is unlikely to remain an attacker secret for long.

The Iranian APT group MuddyWater (also tracked as Seedworm, attributed by CISA, the FBI, and the UK NCSC to Iran's Ministry of Intelligence and Security) has also been observed deploying a previously unknown backdoor called Dindoor that uses the Deno runtime to maintain access within victim networks. Research published on March 5, 2026 by Broadcom's Symantec and Carbon Black Threat Hunter Team documented activity beginning in early February 2026, targeting a U.S. bank, a U.S. airport, non-governmental organizations in the United States and Canada, and the Israeli operations of a U.S. software supplier to the defense and aerospace industries — with the Israeli branch of the software firm appearing to be the primary target. Researchers also observed an attempt to exfiltrate data from the software company using Rclone to a Wasabi Technologies cloud storage bucket, alongside a second Python-based backdoor named Fakeset.

The geopolitical timing of the Dindoor campaign matters. MuddyWater had established these footholds starting in early February 2026 — weeks before the joint U.S. and Israeli military strikes on Iran on February 28, 2026. This pre-positioning indicates that the group was already embedded in U.S. and allied networks before the kinetic escalation began. A Canadian Centre for Cyber Security bulletin assessed Iran as very likely to conduct retaliatory cyber operations against critical infrastructure following the strikes, and Symantec and Carbon Black researchers assessed that the ongoing cyber activity was consistent with that retaliatory posture. The Dindoor backdoor was signed with a fraudulent certificate issued to "Amy Cherne," giving it the appearance of legitimate signed software; Fakeset shared certificate lineage with previously documented Seedworm malware families Stagecomp and Darkcomp, which provided the attribution link confirming MuddyWater's involvement.

Why Traditional Antivirus Cannot Catch This

The four-stage design of this attack chain is specifically engineered around the limitations of conventional endpoint security. Traditional antivirus software works primarily by scanning files written to disk and matching them against known malware signatures. This attack produces no malicious file on disk at any critical stage. The CastleRAT payload exists only in RAM. The carrier JPEG that contains it is a valid image file. The Python environment is renamed to look like a system component. The PyArmor-protected script is, from a file-scanning perspective, a legitimately obfuscated Python file — the same kind developers use daily to protect intellectual property. The execution chain flows through Deno, which has an authentic digital signature and no malicious attributes at the binary level.

Even behavioral monitoring tools face a meaningful challenge here. Behavioral detection works by profiling what processes do — what files they create, what network connections they make, what memory regions they touch. Deno is a general-purpose runtime; it legitimately performs a wide range of operations that could appear normal. This creates a specific defender problem that deserves more direct examination: how do you tell legitimate Deno from malicious Deno?

Legitimate Deno use on an enterprise endpoint has recognizable patterns: it is invoked by a developer interactively, from a known project directory, with specific permission flags, typically during business hours, and it does not spawn portable Python environments, download renamed system tools, or attempt memory injection into other processes. Malicious Deno use in this campaign followed a completely different behavioral profile: it was spawned by a cmd.exe process chain initiated from the Windows Run dialog, it downloaded a portable Python binary with an unusual name, and it produced a child Python process that shortly thereafter attempted to map memory sections consistent with PE loading. None of those behaviors are consistent with any legitimate development workflow. An EDR platform with process ancestry monitoring and memory operation telemetry can distinguish this — but only if it is configured to ask the right questions about Deno activity, rather than treating all Deno processes as trusted by default.

ThreatDown's MDR team succeeded in detecting this campaign through exactly that behavioral approach — identifying anomalous behavior before the attackers reached their objectives, and severing C2 communication before data was exfiltrated. This underscores a key principle in the current threat environment: detection must shift from artifact-based scanning to runtime behavioral analysis, and that analysis must extend to legitimately signed third-party software, not only OS utilities.

Wait — Isn't Deno Supposed to Be Secure?

This is the question the ThreatDown research implicitly invites but does not directly answer, and it deserves one. Deno was designed with security as a central value proposition. Unlike Node.js — which grants every script full system access by default — Deno is built on a permission model that requires scripts to explicitly declare what resources they need: network access, file system access, the ability to spawn subprocesses. No access is granted unless the invoker permits it. The NDSS 2025 research from CISPA Helmholtz Center referenced in the original ThreatDown disclosure confirmed that Deno's permission system works as advertised at the runtime level, with 103 APIs mapped to explicit permission flags.

The security model did not fail here. The attackers simply ran Deno with broad permissions — the equivalent of invoking it with --allow-all, which Deno's own documentation describes as disabling the security sandbox entirely and granting "the same security properties as running a script in Node.js (i.e. none)." That flag exists for legitimate use cases — developers who need it during local development or for trusted internal tooling — but it is also consistently overused. Research into public GitHub repositories found substantial numbers of committed Deno commands using --allow-all or -A, precisely because the alternative (carefully scoping every permission to specific paths and domains) is operationally inconvenient. Attackers invoking Deno in the ClickFix chain did not need to exploit a Deno vulnerability. They needed the user to execute a command that called Deno with full permissions — and ClickFix delivered exactly that.

The NDSS 2025 paper also identified a compounding problem: Deno packages accumulate permissions through their dependency trees. A script that depends on three packages, each with their own permission requirements, can require broader permissions than any single component would suggest — and developers facing unexpected permission prompts at runtime often respond by escalating to coarser-grained grants rather than auditing what triggered the prompt. This is a usability problem that maps directly to a security problem, and it is the same dynamic that made --allow-all common in practice.

The practical implication for defenders is a specific one: Deno's security model is not a compensating control at the endpoint layer, and should not be evaluated as one. The question of whether a Deno invocation carries appropriate permission flags is meaningful for supply chain risk (preventing a malicious Deno package from reaching out to the network without consent) but it is largely irrelevant when the attacker controls the invocation command. When a user pastes a ClickFix command into the Windows Run dialog, they are the one granting the permissions. Deno's sandbox is not in the attack path at all.

This Isn't Just a Deno Problem

The ThreatDown campaign establishes Deno as the first documented instance of a third-party developer runtime being weaponized as a fileless malware delivery vehicle. But the technique generalizes, and there is already evidence the threat landscape is converging on this pattern from multiple directions simultaneously.

In September and November 2025 — months before the Deno-CastleRAT campaign was disclosed — two waves of an npm supply chain worm called Shai-Hulud were documented by Palo Alto Unit 42, Datadog, Checkmarx, and Trend Micro. The second wave, Shai-Hulud 2.0, affected over 25,000 GitHub repositories across roughly 350 maintainer accounts and over 20 million weekly npm downloads. Its infection mechanism was instructive: it injected a preinstall script into legitimate packages that downloaded the Bun JavaScript runtime — another developer tool with no inherent malicious attributes — and then used Bun to execute a heavily obfuscated 10MB payload designed to steal cloud credentials and propagate further through the victim's npm publishing tokens. Datadog's researchers noted explicitly that Bun was chosen to evade standard Node.js process monitoring. The logic is identical to what ThreatDown documented with Deno: use a signed, legitimate runtime that security tooling doesn't flag as anomalous.

Microsoft's Security Blog documented a separate, still-active campaign as of April 2025 in which threat actors were abusing Node.js itself — delivering malware through malvertising disguised as cryptocurrency trading software, then using Node.js's trusted process identity to execute malicious inline scripts and persist on compromised systems. Node.js is present on hundreds of millions of developer and server endpoints globally, and its process-level trust profile is, if anything, more permissive than Deno's.

The pattern across all three cases — Deno, Bun, Node.js — is the same: attackers are systematically identifying developer runtimes that carry inherent process trust, are not yet flagged by security tooling as anomalous, and can execute arbitrary code without touching disk in meaningful ways. Deno is the first to be documented in a nation-state and criminal campaign context with a fileless payload. It will not be the last. Python interpreters, Rust-compiled binaries with legitimate code signatures, Go toolchains, and language-specific package managers are all plausible next candidates. The relevant variable is not which specific runtime is used, but whether security tooling is evaluating what the runtime is doing rather than whether the runtime itself is trusted.

Defender Guidance and Detection Indicators

Security teams should approach this threat from several angles simultaneously. No single control is sufficient, and the surface-level mitigations most commonly cited in threat intelligence reporting — application whitelisting, user training, IOC blocking — address only the entry point of a chain that has multiple fallback layers and adapts quickly. What follows prioritizes controls that address the structural problem rather than this specific campaign's artifacts.

Runtime Behavioral Profiling — Not Just Deno, All Scripting Runtimes

The most commonly cited detection guidance for this campaign is "monitor Deno process ancestry." That is correct but insufficient on its own. A more durable framing is to build a behavioral profile for every scripting runtime present in the environment — Deno, Node.js, Python, Bun, PowerShell, WSH — and treat any deviation from the established profile as an investigation trigger, regardless of whether the deviating runtime is the one currently in active campaigns.

A useful behavioral profile for Deno in a developer environment captures: the parent processes that legitimately invoke it (typically terminal emulators, IDE processes, or task runners — not cmd.exe chains or wscript.exe); the working directories from which it runs (project directories, not %TEMP% or %APPDATA%); the permission flags passed at invocation (specific, scoped flags are legitimate; --allow-all or -A on a production or non-developer endpoint is not); the child processes it spawns (Deno does not legitimately spawn portable Python environments with misspelled names); and the memory operations its children perform (reflective PE loading signatures have known characteristics that EDR platforms with kernel-level telemetry can detect). In non-developer environments, Deno's presence is itself the anomaly — no baseline is needed because the expected baseline is empty.

For EDR platforms that support custom detection rules, the following composite conditions constitute a high-confidence alert:

• Deno process spawned by cmd.exe or wscript.exe, where the grandparent process is explorer.exe (indicating Run dialog origin)
• Deno child process is a Python interpreter located outside of standard Python installation directories or known virtual environments
• The Python child process performs memory-mapped writes that include a PE header signature (MZ) within 60 seconds of launch
• Any of the above processes make outbound connections to IP addresses not present in the organization's DNS-resolved allowlist

MITRE ATT&CK mappings relevant to this chain: T1059.007 (Command and Scripting Interpreter: JavaScript), T1027.003 (Obfuscated Files or Information: Steganography), T1620 (Reflective Code Loading), T1053.005 (Scheduled Task/Job: Scheduled Task), T1056.001 (Input Capture: Keylogging), T1115 (Clipboard Data), T1102.001 (Web Service: Dead Drop Resolver). Mapping to ATT&CK is useful here not because the mappings are novel but because they provide a shared vocabulary for tuning detection rules and communicating scope to leadership.

Windows Defender Application Control as a Structural Mitigation

Application whitelisting is frequently mentioned in threat intelligence guidance and frequently dismissed by practitioners as operationally unmanageable. The objection is valid for traditional whitelisting implementations, which are brittle and create constant operational friction. Windows Defender Application Control (WDAC), however, offers a meaningfully different model that is worth evaluating specifically for this threat class.

WDAC policies can be configured to permit execution of signed software while blocking unsigned or self-compiled payloads, but — critically — they can also be configured with managed installer rules that scope which processes are permitted to install additional software. In the CastleRAT campaign, the Deno installer (clickzpaqkvba.msi) would need to execute successfully for the chain to proceed. A WDAC policy that restricts MSI installation to managed installer contexts (SCCM, Intune, or a designated installer process) would block the initial Deno installation before the chain reaches the obfuscated JavaScript stage. This is a structural control that operates before any behavioral indicator is generated — it removes the attack surface rather than detecting its abuse.

The practical implementation path for most organizations: deploy WDAC in audit mode first to establish a baseline of what software legitimately installs in the environment, then progressively enforce block rules for installation sources outside the managed installer list. Developer workstations require a separate policy that permits broader installation while still logging all installs centrally. The logging itself becomes a detection layer — an MSI install from a user context on a non-developer endpoint in audit mode generates a telemetry event that warrants investigation even before enforcement is active.

Steganography Detection at the Network Layer

The JPEG carrier (CFBAT.jpg) containing the encrypted CastleRAT payload traverses the network when downloaded by the Deno stage. This is a detection opportunity that the original ThreatDown research does not discuss, and most defender guidance ignores because steganography detection is considered computationally expensive and prone to false positives.

Both observations are accurate, but the operational framing matters: full steganography scanning of all network traffic is impractical, but targeted scanning of image files downloaded by scripting runtime processes is tractable. Network security platforms and next-generation firewalls with SSL inspection capabilities can be configured to flag image files (JPEG, PNG, BMP) downloaded by processes in a defined high-risk category — scripting runtimes, development tools invoked outside of their expected execution context. The flag triggers a deeper inspection workflow rather than an automatic block. This is not a generic "scan all images" policy; it is a targeted trigger that activates when the download profile already looks suspicious.

At the endpoint layer, image files appearing in non-user-facing directories (%APPDATA%, %TEMP%, temporary directories created by scripting runtimes) warrant anomaly scoring based on their statistical properties. Steganographically encoded images tend to show measurable deviations in least-significant-bit distributions compared to unmodified images. This statistical analysis is computationally inexpensive at the individual file level and can be implemented as a post-download scan triggered by file creation in high-risk directories — not a real-time scan of all image I/O.

Developer Endpoint Policy Separation

The behavioral baseline problem is most acute on developer endpoints, where Deno, Node.js, Python, portable binaries, and custom build tools are all legitimately present. This creates a genuine tension: the detection controls that would catch this campaign on a standard business endpoint are too noisy on a developer workstation to be operationally useful.

The structural solution is policy segmentation, not a compromise between security and usability. Developer endpoints should be enrolled in a distinct endpoint policy tier with monitoring calibrated to developer behavior — but that monitoring should be more granular, not less. The relevant distinction is not "developers get fewer alerts" but "developer alerts are tuned to developer threat models." A developer endpoint running Deno is normal; a developer endpoint where Deno was installed in the last 24 hours by a process other than a package manager or IDE extension is not. The installation vector, not the presence of the tool, is the signal.

Concretely: developer workstations should have software inventory baselines maintained with higher frequency than standard endpoints (daily rather than weekly), and any new runtime or interpreter installation should generate a notification to the developer and their security team simultaneously. This is not an approval gate — it is visibility. The goal is to surface the "Deno appeared on this machine today" signal quickly enough to investigate while the process chain is still actionable, rather than discovering it during post-incident forensics.

Clipboard Interception as an Early-Chain Detection Opportunity

The ClickFix technique delivers its payload through the clipboard — the user copies a command, pastes it into the Run dialog, and executes it. This creates a detection opportunity at a layer most security tooling does not monitor: clipboard content analysis.

Enterprise endpoint agents that monitor clipboard events can flag clipboard content matching patterns consistent with ClickFix lures: base64-encoded strings exceeding a defined length threshold, PowerShell invocations with encoded commands, or command sequences referencing the %COMSPEC% environment variable, all copied to the clipboard from a browser process. The challenge is false positive rate — developers and IT administrators legitimately copy long commands. The mitigation is to scope the alert to clipboard events originating specifically from browser processes copying content that contains PowerShell or cmd invocations, combined with a browser tab URL that does not resolve to a domain on a known-good list. This composite condition has a substantially lower false positive rate than monitoring clipboard content unconditionally.

Some EDR platforms expose clipboard monitoring as a configurable telemetry source. Where it is available, it is worth enabling specifically to catch ClickFix chains before the command executes — which is the only point in this attack chain where a single, low-cost intervention can sever the entire sequence.

ClickFix Simulation Training — What Actually Works

User awareness training is mentioned in nearly every ClickFix defense recommendation and is nearly always described at the same shallow level: "tell users not to paste commands." That recommendation is correct and also reliably ineffective when delivered as a policy reminder or a static awareness module. The research on simulation-based security training is consistent: passive awareness does not transfer to behavior change under social pressure. What does transfer is repeated, realistic simulation with immediate corrective feedback at the moment of failure.

Effective ClickFix simulation training has specific design requirements that differ from standard phishing simulations. The lure must be rendered as a functioning webpage — not described — because the visual design of the fake browser error or CAPTCHA is central to why the attack works. Users who have seen a described version of ClickFix still fail at meaningful rates when they encounter a visually convincing rendered version, because the recognition cue is visual, not conceptual. The simulation should reproduce the specific friction of the attack: the browser appearing to hang, the official-looking CAPTCHA prompt, the instruction to use the Run dialog. The corrective feedback when the user proceeds should explain what they were about to execute and what it would have done — not just that they failed the test.

Organizations with developer populations should run separate simulations designed for that audience, because ClickFix lures targeting developers use different pretexts than those targeting general users — often faking npm authentication flows, GitHub verification prompts, or IDE extension verification pages. A general-user ClickFix simulation will not produce the recognition cue that matters for a developer encountering a fake npm CAPTCHA.

• Scheduled task auditing for persistence: Enumerate all Scheduled Tasks on endpoints and flag any pointing to Python interpreters in non-standard paths, obfuscated script files, or paths within AppData. The task name VirtualSmokestGuy666 is a specific IOC from this campaign; the more durable detection is any Scheduled Task created by a PowerShell process that was itself spawned by a Python interpreter. Automated task auditing should run continuously. Sigma rules for this creation pattern are detectable via Windows Security Event ID 4698 (scheduled task created) with a creator process path outside of standard management tools.
• Run dialog restrictions via Group Policy: The relevant Group Policy path is User Configuration > Administrative Templates > Start Menu and Taskbar > Remove Run menu from Start Menu. In environments where the Run dialog is not required for legitimate work, this is a low-friction control that removes one of ClickFix's preferred execution vectors entirely. Where the Run dialog must remain available, monitor the RunMRU registry key (HKCU\Software\Microsoft\Windows\CurrentVersion\Explorer\RunMRU) for recently executed commands containing encoded payloads or chained execution strings.
• Network telemetry for scripting runtime C2: Monitor for outbound connections from Deno or Python processes to destinations outside the organization's expected network footprint. Flag connections from scripting runtimes to Steam Community profile URLs — this is documented dead-drop resolver behavior in Velvet Tempest's CastleRAT deployment. Alert on long-lived TCP sessions (over 10 minutes) originating from scripting runtime processes on non-developer endpoints. Confirmed C2 infrastructure from this campaign: dsennbuappec[.]zhivachkapro[.]com (ClickFix C2), serialmenot[.]com (JS loader C2), 172[.]86.123.222 (Python loader C2), 23[.]94.145.120 (CastleRAT C2).
• Memory scanning for reflective PE loading: Enable in-memory scanning configured to detect PE header signatures (MZ\x90\x00) appearing in memory regions allocated by scripting runtime child processes — specifically in regions marked executable that were not mapped from a file on disk. This detection requires EDR with kernel-level memory telemetry. It catches CastleRAT injection regardless of delivery mechanism and does not depend on any campaign-specific signature.
• Cloud storage and Rclone monitoring for exfiltration: Monitor for unexpected Rclone binary installations or executions in defense, financial, and critical infrastructure environments. Alert rules should focus on new binary appearances in user-writable directories, command-line arguments referencing Backblaze or Wasabi bucket names, and transfer volume anomalies — not the presence of Rclone itself, which is a legitimate tool in many organizations.

What Does Remediation Actually Look Like?

The article's own persistence note — that terminating the in-memory CastleRAT process does not remove the infection — is the most operationally important detail in the entire chain, and it warrants a concrete remediation sequence rather than a single callout. IR teams responding to a confirmed CastleRAT infection should treat this as a multi-component removal problem, not a process-kill or endpoint-wipe-and-reimage problem if the environment requires surgical containment.

The minimum set of artifacts to locate and remove:

• The Scheduled Task: Enumerate all tasks on the affected endpoint and remove any pointing to Python interpreters in non-standard paths, obfuscated scripts, or AppData directories. Specifically remove the task named VirtualSmokestGuy666 from this campaign, but treat this as a specific IOC, not an exhaustive check — an attacker adapting the campaign will rename it.
• The JPEG payload carrier: Locate and remove CFBAT.jpg and any other JPEG files in non-standard locations that cannot be associated with a legitimate user or application. The carrier file must be removed to prevent re-injection on the next task execution.
• The Python loader scripts: Locate and remove the PyArmor-obfuscated Python script responsible for decoding the carrier and injecting the payload. Files in AppData with obfuscated names or unusual directory structures should be flagged.
• The renamed Python environment: Remove the "Petuhon" portable Python binary and its associated directory. Any Python environment installed outside of standard program directories or developer-managed paths warrants investigation.
• The Deno installation: In non-developer environments, Deno should not be present. Remove it and audit how it arrived — the MSI file name clickzpaqkvba.msi is a specific IOC from this campaign, but the installer may be renamed in adapted versions.
• Credential rotation: CastleRAT's keylogging and credential-harvesting capabilities mean that any credentials (browser-stored passwords, SSH keys, session tokens for Telegram and Discord) accessible on the endpoint during the infection window must be treated as compromised and rotated before the endpoint is returned to service. This applies to cloud service credentials, developer platform tokens, and any accounts whose credentials were stored in the browser or accessible via the filesystem.
• Lateral movement audit: Given that Active Directory enumeration is documented behavior in related CastleRAT campaigns (specifically the Velvet Tempest operation), IR teams should assess whether the infected endpoint had network access to domain controllers or sensitive internal systems during the infection window, and audit those systems for signs of lateral movement or credential-based access.

A process-kill alone — or even a full endpoint reimaging without the above artifact inventory — leaves open the question of what the attacker did during the dwell period, and whether credentials harvested before detection have already been used elsewhere. The most dangerous part of a CastleRAT infection is not the payload itself but the keylogging and credential-theft window between initial compromise and detection. That window's contents determine the true scope of the incident.

Key Takeaways

1. Living-off-the-land has expanded beyond OS utilities: Attackers are now co-opting third-party developer runtimes with legitimate code signatures. Deno is the first documented example, but the same logic applies to Node.js, Bun, Python, Rust-based tools, and any other signed developer software that a target system might accept. Security models that extend implicit trust to any signed software need to be re-evaluated at the level of behavioral context, not just signature verification.
2. The attack chain is four layers deep, all legitimate: Deno (code-signed runtime) → Petuhon (renamed portable Python environment) → PyArmor-obfuscated Python script (legitimate commercial obfuscation tool) → steganographic JPEG carrier. Each layer is individually explainable as benign developer activity. The malice is in the sequence and what the final layer does to memory — not in any individual component. Signature-based and even basic behavioral tools that evaluate components in isolation cannot catch this.
3. CastleRAT is being adopted broadly and quickly: Multiple distinct threat actor groups — a ransomware affiliate cluster associated with Termite, and an Iranian state-sponsored APT — are deploying CastleRAT or Deno-leveraging tooling, with the Dindoor campaign beginning weeks before any kinetic conflict. This breadth and speed of adoption signals that the technique is effective and being adapted across the attacker ecosystem faster than defender tooling can respond.
4. Detection requires behavioral depth, not just better signatures: Organizations still relying primarily on signature-based antivirus are exposed to this class of attack. Runtime behavioral monitoring, process ancestry analysis, composite alerting on multi-layer chains, and network telemetry are all required. No single layer of detection is sufficient when the attack is designed to look legitimate at every stage individually.
5. The persistence mechanism is the missing piece in many remediation playbooks: CastleRAT survives reboots through a Scheduled Task pointing back to the Python loader, which re-injects the payload from the JPEG carrier. Terminating the in-memory process without removing the task and all associated loader components leaves the infection fully intact. Incident responders and IR playbooks should treat this as a multi-component persistence problem, not a process-kill problem.
6. User education remains a foundational control that many organizations underinvest in: The entire infection chain begins with a user voluntarily executing a pasted command. Technical controls are essential, but they are not a substitute for users who recognize ClickFix lures as an attack pattern. Given that ClickFix is now documented as the initial-access technique for criminal ransomware affiliates and nation-state APTs alike, simulation-based training specifically targeting this technique is warranted.

The broader implication of this research extends beyond CastleRAT. It establishes that trusted developer software — runtimes, interpreters, obfuscators, package managers — is now fair game as an execution vehicle for malware at every tier of the threat landscape, from criminal MaaS operations to state-sponsored APTs. The attack surface is no longer just the operating system's built-in utilities. It is the entire ecosystem of signed, trusted software that developers rely on — and that security tools have historically treated as inherently safe. The question defenders now need to answer is not whether a process is signed, but whether a signed process is behaving consistently with any legitimate reason for its presence on that endpoint. That is a harder question, and answering it requires a fundamentally different approach to endpoint security than the one many organizations currently have in place.