Log InTake a Virtual TourGet a Demo
Research

CastleBot: YARA Rule for Core Backdoor

CastleBot overview 

CastleBot, a rapidly developed malware framework now attributed to threat actor TAG‑150 (per recent Recorded Future reporting), has evolved from “just another loader” into a flexible and sophisticated malware-as-a-service platform gaining operational momentum.

CastleBot has been busy since May 2025, with 469 confirmed infections and a ~28.7% success rate across various methods, from SEO poisoning with trojanized software, to ClickFix phishing, to fake GitHub repositories. The combination of social engineering and a modular architecture lets the threat actor truly flex their payload deliveries in frustratingly efficient ways. TAG‑150’s operational playbook emphasizes efficiency, pairing maldocs with loaders and payloads like infostealers, backdoors, and, more recently, custom implants such as CastleRAT.

The three-act infection chain:

CastleBot malware is composed of three cooperating components: a stager, a loader, and a core backdoor (source: X-Force). Each stage is designed to evade traditional antivirus and endpoint detection. Here’s a quick breakdown: 

Act I (Stager): A small piece of shellcode employs hash-based API resolution (a technique to find system functions with stealth) to dynamically locate system functions during execution and downloads two encrypted payloads — upon XOR decryption, both reveal the CastleBot loader and CastleBot core.

Act II (Loader): The loader uses advanced PE injection to replicate Windows’ native module loading process – including memory allocation, import resolution, and system process manipulation – to ensure the malicious payload appears as a legitimate system component to security monitoring tools. 

Act III (Core Backdoor): The CastleBot core backdoor decrypts its configuration using an embedded XOR key, checks for and creates a mutex to prevent duplicates, then contacts a hardcoded command-and-control server via HTTP to download encrypted data. Once retrieved, that data is decrypted and processed for further instructions. 

Real campaigns 

X-Force documents two great real world cases: a weaponized SSMS installer where Dave Loader injects the CastleBot backdoor, and a Zscaler-themed AutoIt chain that reaches the same payload. In parallel, PolySwarm’s reporting emphasizes ClickFix and fake GitHub repositories luring victims to run malicious commands that fetch the CastleBot loader, promptly followed by distribution of RedLine, DeerStealer, NetSupport RAT, and other loaders. 

Critically, new reporting from Recorded Future (September 2025) connects all of this activity to the actor TAG‑150. This group has since introduced a new backdoor variant, CastleRAT, with both C and Python builds, along with a multi-tiered C2 infrastructure designed for resilience and evasion. TAG‑150 appears to be actively refining their TTPs while maintaining a steady operational tempo.

Core YARA rule, and why context matters

Given CastleBot’s modular design, detection efforts should target family-level artifacts that are consistent across samples. For our research, we focused on the core backdoor stage. During analysis of multiple CastleBot core samples, we identified a recurring serialized type identifier used in its custom data container implementation. While the string may appear as binary gibberish at first, it maps to an internal type signature that the malware uses to handle saved data structures. 

Here is our YARA rule targeting that artifact: 

rule CastleBot_Hunting
{
    meta:
        author="Vincent Zell"
        date="2025-08-12"
        description="hunting aid for CastleBot samples via unique type descriptor"
        hash="202f6b6631ade2c41e4762e5877ce0063a3beabce0c3f8564b6499a1164c1e04"
    strings:
        $string1 = { 2E 3F 41 56 43 6F 6E 74 61 69 6E 65 72 46 69 65 6C 64 49 6E 74 33 32 40 63 6F 6E 74 61 69 6E 65 72 73 40 63 6F 6E 6E 65 63 74 69 6F 6E 40 40 }
    condition:
        $string1
}

This rule matches:

  • An embedded CastleBot core payload within an executable (Core sha256: b45cce4ede6ffb7b6f28f75a0cbb60e65592840d98dcb63155b9fa0324a88be2, Executable sha256: e6aab1b6a150ee3cbc721ac2575c57309f307f69cd1b478d494c25cde0baaf85)
  • An injected CastleBot core payload dropped via Dave Loader (sha256: 202f6b6631ade2c41e4762e5877ce0063a3beabce0c3f8564b6499a1164c1e04)
  • Multiple additional CastleBot core samples observed in the wild

On its own, this rule reliably flags CastleBot core payloads. Within Stairwell, the value grows exponentially when we:

  • Pivot to prevalence – see how often the object appears across environments 
  • Link to campaign clusters – connect hits to related objects from the same campaign.
  • Enrich with file context – identify asset names, file paths, and first/last seen timestamps for rapid incident response

Our platform’s enrichment turns a single YARA hit from a one-off detection into a campaign-wide hunting lead.

Conclusion

CastleBot is no longer “just a loader”, but part of an expanding arsenal run by TAG‑150, a group now demonstrating layered infrastructure, adaptive tooling, and rapid evolution. Their shift from CastleBot to CastleRAT suggests rapid, dedicated ongoing investment, and a long-term offensive roadmap.

We recommend defenders:

  • Pair YARA detections with IOC-based clustering and stager/loader rules
  • Monitor CastleRAT development and TAG‑150 infrastructure changes
  • Leverage contextual enrichment in platforms like Stairwell to scale detections from a single hit to an intrusion-wide response

A layered approach as outlined helps defenders stay one step ahead of a threat actor that’s constantly adapting, and clearly plans to keep it that way. 

 

Background pattern