- CastleRAT is the first documented malware to abuse the Deno JavaScript runtime — a legitimate, code-signed developer tool — to execute obfuscated scripts entirely in memory, bypassing traditional antivirus engines.
- The attack uses steganography to hide an encrypted payload inside a JPEG image, meaning there is no standalone malicious executable written to disk for file-based scanners to find.
- Because Deno is a trusted, code-signed process, its activity inherits elevated system trust — behavioral alarms that would fire on unknown executables simply don’t trigger.
- Traditional signature-based antivirus tools are blind to this attack — only behavior-based EDR solutions monitoring in-memory execution and process anomalies have a realistic chance of catching it.
- This attack signals a dangerous expansion of living-off-the-land techniques beyond OS utilities like PowerShell into developer runtimes — a shift every security team needs to prepare for now.
A completely trusted, code-signed developer tool just became a delivery vehicle for one of the most evasive malware campaigns ever documented.
ThreatDown’s Endpoint Detection and Response (EDR) team uncovered what researchers believe to be the first documented case of attackers abusing the Deno JavaScript runtime as a malware execution framework. This isn’t a vulnerability in Deno itself. The attackers simply picked up a legitimate tool, pointed it at obfuscated code, and let the operating system’s own trust model do the rest. ThreatDown, the security division behind this research, focuses specifically on identifying emerging attacker tradecraft that evades conventional defenses.
Attackers Are Now Hiding Inside Tools You Already Trust
The core problem here isn’t a zero-day or an unpatched vulnerability. It’s something harder to fix: attackers have learned that your defenses are built around identifying what is running, not how it’s behaving. When a code-signed, legitimate binary like Deno executes a script, most security tools see a green light and move on.
Deno is widely used by developers for running JavaScript and TypeScript server-side applications. It was created by Ryan Dahl, the original creator of Node.js, and is actively maintained and distributed as a trusted developer utility. Its digital signature from a recognized publisher means Windows and most enterprise security tools treat it as inherently safe. That trust is exactly what the attackers exploited.
Why This Attack Is Different From Previous Malware Campaigns
Previous living-off-the-land attacks typically abused tools already present on a system — PowerShell, WMI, certutil, or mshta. The CastleRAT campaign breaks new ground by bringing in an external trusted tool — Deno — and installing it specifically to use as a malware execution engine. This means the attacker’s footprint looks like a developer setting up a legitimate work environment, not like an intrusion.
The payload itself never touches disk as a standalone executable. Instead, it is encrypted and hidden inside a JPEG image file using steganography, then decrypted and loaded directly into memory at runtime. Every stage of the attack is designed to look normal to tools that rely on file hashes, known signatures, or static disk scanning.
CastleRAT: What It Does Once It’s in Your Memory
Once CastleRAT is loaded into memory, it operates as a full remote access trojan — giving attackers persistent, interactive access to the compromised system. Because it lives entirely in memory, it leaves minimal forensic artifacts. The combination of memory-only execution, steganographic payload delivery, and trusted process abuse makes CastleRAT one of the most technically sophisticated evasion chains documented against enterprise environments to date.
What Is Deno and Why Attackers Chose It
Deno is a modern JavaScript and TypeScript runtime built on the V8 engine and Rust. It was designed as a more secure alternative to Node.js, with built-in permission controls and a sandboxed execution model. Developers use it to run server-side scripts, automate tasks, and build web applications. It supports TypeScript natively, has a built-in test runner, and ships as a single executable — which ironically makes it trivial to drop onto a target system without complex installation procedures.
Why Deno was the ideal choice for this attack:
Attribute Why It Matters to Attackers Code-signed binary Bypasses trust-based security controls and application allowlisting Single executable Easy to drop on a target system without an installer or dependencies Legitimate developer use Presence on a system raises no immediate red flags to analysts Supports obfuscated scripts Can execute heavily obfuscated JavaScript without modification Active open-source project Continuously updated, so security tools rarely flag it as suspicious
Deno Is Legitimate, Code-Signed Developer Software
The digital signature on Deno’s binary is a critical piece of why this attack works. Enterprise environments often use application control policies that trust signed binaries from known publishers. When Deno executes, it doesn’t trigger those controls. The operating system and most endpoint security tools treat it identically to how they’d treat a browser or a development IDE — as something that belongs there.
How Trusted Processes Inherit System Privileges
When Deno runs on a system, it inherits the privileges of the user context it runs under. If an attacker has already gained access to an account with local administrator rights — which is common in enterprise environments where developers often have elevated permissions — then Deno runs with those same privileges. Any code Deno executes, including the obfuscated CastleRAT loader, runs with that same level of access. There’s no privilege escalation needed because the trusted process already carries the required permissions.
Living-Off-the-Land Attacks Expanded Beyond OS Utilities
Living-off-the-land (LotL) attacks have been a dominant technique in advanced threat campaigns for years. The premise is straightforward: use tools that are already present and trusted on the target system to avoid introducing suspicious new files. Security teams have built detection rules, behavioral baselines, and threat hunting playbooks specifically around the known LotL toolset — PowerShell, WMI, WMIC, certutil, regsvr32, and others.
The CastleRAT campaign breaks that assumption. Attackers are no longer limited to abusing what’s already installed. They’re now bringing their own trusted binaries — developer runtimes with legitimate code signatures — and using them as execution engines. This represents a meaningful expansion of LotL tradecraft that security teams need to account for immediately.
The implications extend well beyond Deno. If one developer runtime can be weaponized this way, the same logic applies to others. Security teams that have built their detection strategies around a fixed list of known LotL tools now need to extend that thinking to any legitimate, signed runtime that can execute scripts or load code.
- PowerShell and WMI — still heavily abused, but well-monitored in mature environments
- Node.js — similar runtime architecture to Deno, single executable, widely trusted
- Python interpreter — commonly present in developer and data science environments
- Deno — now confirmed as an active malware execution vehicle in the CastleRAT campaign
- Other signed runtimes — any code-signed interpreter or script host is a potential candidate for this technique
The Three-Stage Infection Chain
Understanding exactly how this attack unfolds is essential for building detection logic that can actually catch it. The CastleRAT campaign follows a deliberate three-stage sequence, where each stage is specifically designed to look benign in isolation. It’s only when you trace the full chain of behavior that the malicious intent becomes clear — which is exactly why behavior-based EDR telemetry is the only reliable way to catch it.
Stage 1: Initial Access and Deno Runtime Installation
In the first stage, attackers establish a foothold on the target system and deploy the Deno runtime binary. Because Deno ships as a single self-contained executable, dropping it onto a compromised system is as simple as copying one file. No installation wizard, no registry entries from an installer, no dependency chain to trip detection rules. The binary lands, and it’s immediately ready to execute scripts. At this stage, the activity looks consistent with a developer or IT administrator setting up a scripting environment.
Stage 2: Steganography — The Payload Hidden Inside a JPEG Image
This is where the attack gets technically sophisticated. Rather than storing the CastleRAT payload as a recognizable executable or script file, the attackers encrypted it and embedded it inside a JPEG image file using steganography. Steganography is the practice of hiding data inside another file — in this case, concealing encrypted malicious code within the pixel data or metadata of a seemingly normal image. File-based antivirus tools scan for known malicious patterns. An encrypted blob hidden inside a JPEG produces no such pattern match.
When the Deno-executed script runs, it reads the image file, extracts the hidden encrypted payload, decrypts it in memory, and prepares it for execution — all without ever writing the decoded payload to disk as a standalone file. From a file system perspective, the only thing that exists is an image file that looks completely unremarkable.
Stage 3: In-Memory Execution of CastleRAT
Once the encrypted payload is extracted from the JPEG and decrypted, Deno loads it directly into system memory and executes it — never writing the final RAT to disk. CastleRAT then runs entirely as a memory-resident process, inheriting the privileges of the Deno runtime that launched it. From this point forward, the attacker has interactive remote access to the compromised system: they can execute commands, exfiltrate data, move laterally, and maintain persistence — all from within what the operating system still considers a trusted developer process.
Why Traditional Antivirus Fails Against This Attack
Traditional antivirus was built for a different threat landscape. It works by scanning files on disk, comparing them against a database of known malicious signatures, and blocking execution when a match is found. That model has one fundamental weakness: it requires a file to exist on disk in a recognizable form. The CastleRAT campaign was specifically engineered to exploit that weakness at every single stage.
File-Based Scanning Cannot Detect Memory-Only Payloads
When the final CastleRAT payload never touches disk as a standalone executable, file-based scanners have nothing to scan. The JPEG image that carries the encrypted payload doesn’t match any known malicious signature because it’s just an image with encrypted data embedded in it. The decrypted payload only ever exists in memory — and by the time an attacker is issuing commands through the RAT, there’s no file artifact left for a scanner to find. Even if you ran a full disk scan on the compromised system at that moment, it would come back clean.
Code-Signed Software Bypasses Trust Verification
Application control solutions and endpoint security tools that rely on digital signature verification face a fundamental problem with this attack: Deno passes every trust check. It has a valid code signature from a recognized publisher. It’s not a modified or tampered binary. It’s the real, legitimate Deno runtime — and that’s precisely why it bypasses trust verification. Security tools that ask “is this binary signed and trusted?” will always answer yes to Deno, regardless of what scripts it’s been instructed to run.
How to Detect a Deno-Based Attack on Your Network
Detection requires shifting your focus from what files exist to what processes are doing. The CastleRAT campaign leaves very few file-based artifacts, but it does generate behavioral signals that a well-configured EDR solution can capture. The key is knowing exactly what to look for and having the telemetry depth to see it.
The most important mindset shift for defenders here is this: Deno’s presence on an endpoint is not automatically suspicious, but Deno’s behavior absolutely can be. A developer using Deno to run a build script looks completely different in EDR telemetry from an attacker using Deno to decode a JPEG and inject a payload into memory. The behavioral fingerprint of the attack is distinct — you just need the right instrumentation to see it.
- Deno process spawning unexpected child processes — especially shells, network utilities, or system enumeration tools
- Deno making outbound network connections to external IPs or domains not associated with legitimate Deno package registries
- Image files being opened by a scripting runtime — a JPEG being read by Deno.exe is not normal developer behavior
- Memory allocation anomalies within the Deno process — large, executable memory regions being created dynamically are a strong indicator of in-memory payload loading
- Deno installed in non-standard directories — legitimate developer installs typically land in predictable locations; attacker-dropped binaries often don’t
- No parent process consistent with developer activity — Deno launched by a script, scheduled task, or unknown parent process rather than a terminal or IDE is a red flag
None of these indicators alone is a guaranteed confirmation of compromise. But two or more occurring together — especially Deno reading an image file followed immediately by outbound network connections — should trigger immediate investigation.
Behavioral Indicators to Monitor in EDR Telemetry
Your EDR telemetry needs to capture process creation events with full command-line arguments, memory allocation events flagging executable regions created at runtime, file read events showing which processes are accessing which file types, and network connection events tied to specific process IDs. Without all four data streams, you will have blind spots. ThreatDown’s EDR team was able to uncover this campaign specifically because they had that depth of telemetry available across the affected endpoints. Solutions that only log process creation events without memory or file-access context would likely have missed the key indicators that exposed this attack chain.
Suspicious Deno Process Activity and Network Connections
In a legitimate developer environment, Deno typically makes network connections to fetch dependencies from the Deno standard library or third-party module registries hosted at known, stable domains. Connections to newly registered domains, raw IP addresses, or domains with randomized substrings in the hostname are immediate anomalies. Threat hunters should baseline normal Deno network behavior in their environment and alert on any deviation — particularly connections initiated shortly after a Deno process reads a non-JavaScript file.
Command-line arguments passed to the Deno executable are another critical signal. Legitimate Deno usage involves clear, readable script paths and well-defined permission flags. The CastleRAT attack used obfuscated scripts, meaning the command-line arguments or the script content itself will look deliberately obscured. EDR rules that flag Deno invocations with encoded, Base64-encoded, or otherwise obfuscated argument strings can provide early detection before the payload even decrypts.
Image File Analysis for Hidden Encrypted Payloads
Detecting steganographic content in image files at enterprise scale is genuinely difficult, but there are practical approaches that can help. First, flagging any scenario where a script interpreter or runtime reads an image file and then immediately allocates executable memory is a strong behavioral correlation rule. Second, network-level inspection can identify image files being retrieved from external sources by scripting runtimes — a JPEG being downloaded by Deno.exe rather than a browser or image viewer is an anomaly worth investigating. File entropy analysis can also help: encrypted payloads hidden inside images typically produce abnormally high entropy values in sections of the file that should contain low-entropy pixel data.
Prevention: How to Stop This Attack Before It Starts
Prevention here requires layering multiple controls because no single countermeasure stops this attack chain entirely. Each stage of the infection — initial access, Deno deployment, payload retrieval, in-memory execution — has its own set of defensive controls. Addressing only one layer leaves the others exposed. The goal is to make each stage of the attack harder, noisier, and more likely to be caught before it progresses.
1. Audit and Restrict Unauthorized Runtime Installations
Start with a clear, enforced policy on which runtimes are permitted in your environment and where. If Deno is not an approved developer tool in your organization, its presence on any endpoint should immediately trigger an alert. Implement application control policies — using tools like Windows Defender Application Control (WDAC) or AppLocker — that restrict which executables can run, even if they are legitimately signed. A signed binary from a trusted publisher should still require explicit approval to execute in your environment.
For environments where Deno is legitimately used, implement a software inventory baseline. Know exactly which endpoints should have Deno installed, which versions are authorized, and which user accounts are permitted to run it. Any deviation from that baseline — a new Deno installation on a non-developer workstation, or a different version appearing unexpectedly — should generate a high-priority alert in your SIEM.
2. Deploy Behavior-Based EDR Instead of Signature-Based Tools
This attack makes the case for behavior-based EDR more clearly than almost any other recent campaign. Signature-based antivirus had zero ability to detect this attack at any stage — the Deno binary is clean, the image file is clean, and the payload never exists on disk in a scannable form. Behavior-based EDR, by contrast, can observe the full chain of events: runtime reading an image, allocating executable memory, and initiating unexpected network connections. That chain of behavior is detectable regardless of whether any individual component has a known malicious signature.
When evaluating EDR solutions for this type of threat, prioritize platforms that provide memory scanning capabilities, not just process and file monitoring. The ability to inspect the contents of memory regions allocated by running processes — and flag regions that contain executable code created dynamically at runtime — is what separates EDR tools that can catch CastleRAT-style attacks from those that cannot. ThreatDown’s EDR team detected this campaign through exactly this kind of deep behavioral telemetry.
3. Monitor Trusted Process Execution for Anomalous Behavior
Every legitimate application in your environment has a behavioral baseline — a predictable pattern of what processes it spawns, what files it reads, and what network connections it makes. Deno used by a developer to run a build script looks nothing like Deno used by an attacker to decode a JPEG and load a RAT into memory. Build process execution monitoring rules that specifically track what trusted, code-signed runtimes do after they launch, not just whether they launched. A Deno process that reads an image file, allocates executable memory, and then opens a network socket to an external IP is exhibiting a behavioral sequence that has no legitimate developer explanation.
4. Apply Least-Privilege Principles Across Developer Environments
Developer workstations are frequently over-privileged. Developers often need local administrator rights for legitimate reasons — installing dependencies, running build tools, debugging applications — but those elevated privileges become a significant liability when an attacker drops Deno onto the system and runs it in that user context. Apply least-privilege principles rigorously, even in developer environments. Where full local admin rights are genuinely required, consider privileged access workstation (PAW) configurations that segment high-privilege activity from general internet-facing use. Reducing the privilege level that Deno inherits when it executes directly limits the blast radius of an attack that successfully deploys this technique.
5. Scan Incoming Image Files for Embedded Encrypted Data
Implement file entropy analysis on image files entering your environment — whether through email, web downloads, or file shares. Legitimate JPEG images contain pixel data with predictable entropy characteristics. A JPEG carrying an encrypted payload will show anomalously high entropy values in sections of the file that should not contain high-entropy data. Network security tools with deep packet inspection capabilities can perform this analysis at the perimeter. Internally, endpoint controls that flag script runtimes opening image files and then allocating executable memory provide a second layer of detection specifically for the steganographic extraction stage of this attack chain.
This Attack Signals a Broader Shift in Attacker Tradecraft
The CastleRAT campaign isn’t just a novel malware variant — it’s evidence of a deliberate strategic evolution in how sophisticated threat actors approach evasion. For years, the security industry has played a reactive game against living-off-the-land techniques, building detection rules around a known set of abused OS utilities. Attackers have now taken the next logical step: if defenders have hardened detection around built-in OS tools, bring in a trusted external tool instead. The attack surface for this technique is enormous because the number of legitimate, code-signed developer runtimes and scripting environments in common use is large and growing.
Every security team needs to update their threat model to include the scenario of a trusted, signed third-party binary being used as a malware execution engine. Detection strategies built exclusively around known LotL tools like PowerShell and certutil will miss this class of attack entirely. The practical implication is clear: your detection logic needs to follow behavior, not just identity. A process being signed and trusted tells you what it is — it tells you nothing about what it’s doing. Building security controls around that distinction is the most important defensive takeaway from the CastleRAT campaign.
Frequently Asked Questions
The CastleRAT and Deno runtime campaign raises important questions for security professionals working to understand and defend against this new class of attack. The following answers address the most critical technical questions directly.
What Is Fileless Malware and Why Is It Hard to Detect?
Fileless malware is malicious code that executes entirely in system memory without writing a standalone executable to disk. Traditional antivirus and endpoint protection tools are designed to scan files stored on disk, comparing them against databases of known malicious signatures. When the malicious payload only ever exists as decrypted code in a memory region — never as a file with a hash that can be matched against a signature database — those tools have nothing to scan. Fileless malware is hard to detect because the primary artifacts it leaves behind are behavioral, not file-based: unusual memory allocations, unexpected process behavior, and anomalous network connections rather than suspicious files in predictable locations.
Can Deno Itself Be Patched to Prevent This Type of Abuse?
No — and this is an important distinction to understand. The Deno runtime itself has no vulnerability that is being exploited here. Attackers are not taking advantage of a bug or security flaw in Deno’s code. They are simply using Deno exactly as it was designed to work: running JavaScript code. Patching Deno would have no effect on this attack technique because the runtime is functioning correctly. The defensive solution is not a software patch — it is a combination of access controls, behavioral monitoring, and application control policies that govern whether Deno is permitted to run in a given environment and what it is permitted to do when it runs.
What Is CastleRAT and What Can It Access on an Infected System?
CastleRAT is a remote access trojan — a category of malware that gives an attacker persistent, interactive remote control over a compromised system. Once loaded into memory via the Deno-based attack chain, CastleRAT provides the attacker with the ability to execute arbitrary commands on the infected machine, navigate the file system, exfiltrate data, capture keystrokes or screenshots, and use the compromised endpoint as a staging point for lateral movement deeper into the network.
Because CastleRAT runs in memory with the privileges inherited from the Deno process — which in turn inherits from the user account that launched it — its access level is directly tied to how privileged that account is. On an over-privileged developer workstation with local admin rights, CastleRAT effectively has unrestricted access to the local system and potentially to network resources that account can reach. This is why least-privilege enforcement in developer environments is a critical prevention control, not just a compliance checkbox.
Are Other JavaScript Runtimes Like Node.js at Risk of Similar Abuse?
Yes — and security teams should treat this as a category-level risk, not a Deno-specific problem. The technique that makes CastleRAT’s delivery mechanism effective is not unique to Deno. Any legitimate, code-signed runtime that can execute scripts, fetch remote resources, and interact with system memory is theoretically usable in the same way. Node.js shares almost all of the same characteristics that made Deno attractive for this attack: it is code-signed, widely trusted, ships as a standalone executable, and can execute obfuscated JavaScript.
The practical difference between runtimes is largely one of attacker preference and operational security. Deno may have been chosen specifically because it is less commonly present in enterprise environments than Node.js — meaning its presence might receive less scrutiny in environments where Node.js is a known and monitored quantity. As defenders build detection rules specifically for Deno-based attacks, attackers may shift to Node.js, Bun, or other runtimes that occupy a similar trust position. Getting ahead of that shift requires building detection logic around runtime behavior generically, not just creating rules for Deno specifically.
- Node.js — code-signed, widely distributed, can execute obfuscated JavaScript and make arbitrary network connections
- Bun — newer JavaScript runtime, growing developer adoption, ships as a single signed executable
- Python interpreter — present in enormous numbers of enterprise environments, can execute heavily obfuscated code, widely trusted
- Ruby interpreter — common in development and DevOps environments, similar code execution capabilities
- PHP CLI — frequently present on web servers and development systems, can execute remote scripts
The unifying characteristic across all of these is that they are legitimate tools designed to execute code — and that code execution capability is exactly what attackers want. Any runtime that can run scripts, allocate memory, and make network connections is a candidate for this type of abuse.
The detection principle remains consistent regardless of which runtime an attacker chooses: monitor trusted runtimes for behavioral anomalies, not just for their presence. A runtime reading an image file and then allocating executable memory is suspicious no matter which runtime binary is involved. Build your detection rules at the behavioral pattern level and they will generalize across the entire category of potential runtime abuse.
How Do Attackers Use Steganography to Hide Malware Inside Images?
Steganography is the practice of hiding data inside another file in a way that isn’t visually or obviously detectable. In the CastleRAT campaign, the malicious payload was encrypted and embedded within a JPEG image file. A JPEG is made up of compressed pixel data, metadata headers, and various optional data segments — and an attacker can embed arbitrary data within those structures in ways that don’t meaningfully alter how the image looks when displayed. The resulting image file opens normally in any image viewer and produces no obvious visual indication that it contains anything other than pixel data.
The extraction process happens entirely in code. The Deno-executed script knows exactly where in the image file the payload is hidden, reads the image as raw bytes rather than as a displayed image, extracts the relevant byte sequences, and passes them through a decryption routine to recover the original payload. This all occurs in memory — the image is read, the payload is extracted and decrypted in RAM, and then executed without any intermediate step that involves writing the decoded payload to disk as a file. From the perspective of the file system, only the original JPEG ever existed.
Detecting this technique requires moving beyond file content analysis into behavioral correlation. The tell is not in the image file itself — a sufficiently well-crafted steganographic image will pass most static inspection. The tell is in the behavior: a script runtime reading an image file immediately followed by dynamic memory allocation of an executable region. That specific behavioral sequence — runtime opens image, runtime creates executable memory — is the detection signal that security teams should be building alerts around, regardless of which image format or which runtime is involved in a given attack.