Dissecting the CastleBot Malware-as-a-Service operation

IBM X-Force has been investigating a newly emerging malware framework named CastleBot. The malware is believed to be part of a Malware-as-a-Service (MaaS) operation and is specifically designed for flexible malware deployment. CastleBot is currently used by cyber criminals to deliver everything from infostealers to backdoors like NetSupport and WarmCookie, which have been linked to ransomware attacks.

What makes CastleBot particularly concerning is how it's being distributed: most often through trojanized software installers downloaded from fake websites, luring unsuspecting users into launching the infection themselves. This technique is part of a growing trend X-Force is observing. It is often enabled through SEO poisoning, which causes malicious pages to rank higher in search engines than legitimate software distributors. Once inside, CastleBot runs through a three-stage process: a stager/downloader, a loader and a core backdoor, which requests a set of tasks from its command and control (C2) server. Information gathered from the infected machine allows operators to easily filter victims, manage ongoing infections and deploy malware to high-value targets with precision.

CastleBot is still evolving, and our research shows it's likely just getting started. In this report, we break down how it works, how it spreads, and why it matters.

• CastleBot is a new malware likely operated as a Malware-as-a-Service, which can be used to deliver a wide range of malicious payloads
• Follow-on payloads range from infostealers to backdoors linked to ransomware attacks, such as NetSupport and WarmCookie
• X-Force observed trojanized software installers as the most common infection vector to deliver CastleBot
• The CastleBot framework encompasses three components: a stager, loader and a core and appears to be under active development
• The malware seems to allow operators to easily filter victims, update payloads and manage multiple campaigns throughout their lifecycle

CastleBot first appeared in early 2025. X-Force noted an increase in the volume of samples and different payloads starting in May, and has since observed the deployment of various backdoor and infostealer payloads. CastleBot's most common infection vector is trojanized software, which is part of a trend X-Force continues to observe since 2024. Trojanized software packages and installers are often distributed via fake websites using SEO poisoning to attract victims. CastleBot was also distributed through GitHub repositories, impersonating legitimate software, and via the popular ClickFix technique.

X-Force identified three components as part of the CastleBot malware framework: a stager, a loader and the CastleBot core/backdoor.

Note that previous public reporting by Prodraft refers to the same malware framework as "CastleLoader".

In most cases, the CastleBot core component is deployed via a shellcode stager, which is part of the same CastleBot malware family. The stager is a lightweight shellcode payload that can be injected by any other first-stage loader. X-Force observed various crypters used with CastleBot, including Dave, an AutoIt-based crypter, and simple crypters compiled in C.

The malware uses the DJB2 hashing algorithm to resolve necessary APIs at runtime. Before every API call, it loads the corresponding DLL and traverses the Export Address Table (EAT) searching for the API function via pre-generated DJB2 hashes. Should the export be forwarded to another DLL, the stager parses the DLL name, loads it and resolves the function via GetProcAddress.

Upon execution, the stager downloads two payloads via HTTP with the User Agent "Googlebot". The URL paths are similar between samples and address the same C2 server as the CastleBot core component.

Example download URLs:

Both payloads are decrypted via a hardcoded XOR string, in this case "GySDoSGySDoS" (UTF-16 encoded), revealing a PE (CastleBot core) and a shellcode stub (CastleBot Loader).

The stager then uses VirtualProtect to enable execution on the heap for the memory region storing the second decrypted shellcode payload. The latter, acting as a loader, is executed directly in memory and receives a pointer to the decrypted PE as an argument.

The CastleBot Loader is a fully-featured PE loader, which begins by mapping each section of the provided PE into a new memory region allocated using NtAllocateVirtualMemory. It goes on to fix any necessary relocations, resolve imports, set the appropriate memory protection options and execute existing TLS callback functions.

Notably, the loader also sets up a new LDR_DATA_TABLE_ENTRY structure and the corresponding LDR_DDAG_NODE (extended in Windows 8 and later), which are then added into the PEB_LDR_DATA doubly linked lists containing the loaded modules for each process. To EDR agents monitoring the PEB, this would make the injected payload appear more as though it was legitimately loaded by the operating system.

Unless the injected file is a DLL, the PEB's ImageBaseAddress field is also set to the base address of the injected payload.

Lastly, to execute the payload, CastleBot Loader executes the entry point or allocates a new console for console applications.

In the sample analyzed above, the injected payload is the x86 CastleBot backdoor (202f6b6631ade2c41e4762e5877ce0063a3beabce0c3f8564b6499a1164c1e04).

The CastleBot core uses the same API resolution mechanism as the stager and loader components, except for the hashing algorithm, which is the AP hash, developed by Arash Partow.

First, the backdoor begins by decrypting its configuration. Almost all strings throughout the binary, including those part of the configuration, are stored as UTF-16 and decrypted inline via a unique 4-byte XOR key for each string. During decryption, the following configuration struct is created:

The malware attempts to create a mutex, using the name from the config, to ensure only a single instance is running. In the next step, it sends an HTTP GET request to the hardcoded URL to retrieve its settings, using the campaign ID in the URL path:

In response, CastleBot receives a block of encrypted data.

All C2 communication is encrypted via the symmetric ChaCha algorithm, apart from the malware's initial GET request. After decryption, the C2 protocol uses a serialized custom data structure, internally referred to as container, which can store values of different types.

At the root of the serialized data structure is always a field of type ContainerFieldArray. The structures below further define how array and bool types are set up:

When parsing the decrypted container defining the settings requested by the backdoor, the data starts with the byte 0x0D, indicating the type ContainerFieldArray. That byte is followed by the field name, which itself is the 2-byte length followed by the UTF-16 encoded name. After the name, an array field defines a 4-byte length of the data, followed by the data itself, which again starts with the first byte defining the type.

The settings received by the sample analysed above are parsed as follows.

Serialized data:

Deserialized object:

For each enabled setting, the following actions are performed by CastleBot:

run_as_admin: The malware will execute its parent via "cmd.exe /c <parent_process>" via ShellExecuteW with the "runas" verb to launch it as Administrator.

anti_vm: CastleBot will use the cpuid instruction with the 0x40000000 leaf to attempt to detect hypervisor environments. If either VMware or Parallels is discovered, the malware will exit.

prevent_restart: CastleBot will create a new hidden file in %PROGRAMDATA% with the name matching the mutex name embedded in the configuration. If the file already exists, the malware will exit.

show_fake_error: The malware displays a message box "System Error" with the message "The program can't start because VCRUNTIME140.dll is missing from your computer. Try reinstalling the program to fix this problem."

In the next step, CastleBot gathers information on the infected host to register with the C2 server and request tasks.

• Username via GetUserNameW
• NetBIOS name via GetComputerNameW
• System architecture via IsWow64Process
• Local DNS domain name, by using LsaQueryInformationPolicy to retrieve the PolicyDnsDomainInformation structure. Default value is "WORKGROUP".
• Volume serial number retrieved via GetVolumeInformationW. CastleBot uses it to calculate a unique victim ID using a linear congruential generator (LCG) with a multiplier of 0x41C64E6D and an addend of 0x3039.
• Windows version via RtlGetVersion and GetSystemMetrics(89)

The information is compiled into the object below, followed by serialization and ChaCha encryption:

The hardcoded values are the access key (identical to the User-Agent from the configuration), the campaign identifier and the CastleBot build version, which is "1.0" for the analyzed sample.

The backdoor sends the encrypted data in an HTTP POST request to

 The response is a larger encrypted container bearing the CastleBot's pre-configured tasks.

The container received from the C2 server by the analyzed CastleBot sample is decrypted and deserialized into an object with the following fields:

The "tasks" field is a custom type of array as detailed above, containing at least one unnamed array (zero-length name), each representing a task. CastleBot may also receive an array with multiple tasks to be carried out after each other. Each task contains an ID and several fields detailing how the task is to be executed, which are copied into a task structure during deserialization.

The most important field in each task is the "launch_method", which determines the type of payload to be handled by CastleBot.

The other fields may be used to set specific options for the task execution:

CastleBot supports simple process injection for PE payloads. It begins by creating a new suspended process, based on the install path and argument fields. In order to work on Windows 11 24H2 and later, the malware developers chose to hook NTDLL's NtManageHotPatch function in memory to bypass the newly added memory check. See Hasherezade's post for more details, which also provides the exact POC implementation used by CastleBot:

The rest of the process injection follows common injection techniques by allocating memory in the target process, writing the sections into the buffer and modifying the thread context before resuming execution.

If the startup method field is set to "1", CastleBot establishes persistence by creating a scheduled task. To register the task, the malware uses the ITaskService COM interface to connect to the Task Scheduler service. It creates a new task and an execute action for the target payload, which is triggered every time the current user logs on (TASK_TRIGGER_LOGON).

Each task in the "tasks" container is handled iteratively according to its specified fields. Once a task has been completed without errors, the malware reports back the successful execution via an HTTP GET request to:

X-Force observed an updated CastleBot core variant, supporting new launch methods and an option called "wow64_bypass", used to specifically launch 32-bit system binaries in the SysWOW64 folder.

The additional process injection implementation (launch method 6) writes both the CastleBot Loader component (see analysis section above) as well as the PE payload into the target process. It then uses QueueUserAPC and ResumeThread to transfer execution to the loader, which properly loads the PE payload into memory and executes it.

This technique uses significantly fewer WriteProcessMemory API calls and provides a more complete loading functionality from the CastleBot Loader stub.

CastleBot's main objective is to enable the deployment of secondary payloads onto victim machines. X-Force uncovered several different payloads distributed by CastleBot, often with multiple payloads in a single campaign. Payloads vary in sophistication, from commodity infostealers to more capable backdoors such as NetSupport or WarmCookie, which have been linked to ransomware attacks.

The CastleBot MaaS framework appears to allow operators to filter infected machines and easily update payloads to manage multiple active campaigns with great flexibility, according to Prodaft's analysis and screenshots of the C2 panel. With the fluidity of payloads and the operator's ability to add multiple tasks and payloads to a single campaign, CastleBot infection chains are more complex in comparison to traditionally static malware stages.

X-Force does not have any evidence of a widespread advertisement of the MaaS on the dark web, which might indicate that the service is currently only sold to a private group of affiliates.

Without identifying the malware as its own framework, various fragments of the campaigns leading to NetSupport were publicly reported on by other researchers in June and July 2025.

DomainTools observed fake DocuSign pages employing the ClickFix technique to execute a malicious PowerShell script, which in turn downloads CastleBot to deploy NetSupport. Campaign IoCs:

PaloAlto's Unit42 reported similar activity with websites imitating DocuSign and Okta, using ClickFix to deploy CastleBot via the initial stager and loader components. It contains a partial analysis of a "NetSupport RAT Loader", which X-Force identifies as the CastleBot framework. Campaign IoCs:

One of the more interesting payloads of CastleBot is the WarmCookie backdoor (aka Quickbind, BadSpace). It is likely part of a larger cyber crime ecosystem enabling ransomware attacks and was among the malware families successfully targeted by international law enforcement during Operation Endgame in 2024. Previously, the threat actor Hive0137 distributed WarmCookie via malicious email campaigns, though no significant activity has been observed in 2025, according to X-Force's visibility. WarmCookie is publicly tied to TA866/Asylum Ambuscade operations.

The campaign X-Force observed began in June with a weaponized ZIP archive imitating an installer for a legitimate software SSMS-20.2-enu.zip (4766f5cc6501fc40c7151a0ce1c9d2cc49fca9b0b9cab2a206dd2426947e9afe). Among the legitimate components, it contains a malicious executable SSMS_Windows.x64.exe (05ecf871c7382b0c74e5bac267bb5d12446f52368bb1bfe5d2a4200d0f43c1d8) identified as a variant of Dave Loader, which decrypts a payload stored within its resources. After decryption, Dave Loader injects the CastleBot backdoor (202f6b6631ade2c41e4762e5877ce0063a3beabce0c3f8564b6499a1164c1e04), which receives the task to download and execute a WarmCookie payload (5bca7f1942e07e8c12ecd9c802ecdb96570dfaaa1f44a6753ebb9ffda0604cb4) from

The WarmCookie C2 server is located at:

A second sample found later in June used a similar executable, imitating an installer for Zscaler software Zscaler-windows-4.4.0.379-installer-x64.exe (bf21161c808ae74bf08e8d7f83334ba926ffa0bab96ccac42dde418270387890). The AutoIt-compiled binary is a simple shellcode loader, executing the embedded CastleBot stager, which in turn downloads the same CastleBot backdoor binary (202f6b6631ade2c41e4762e5877ce0063a3beabce0c3f8564b6499a1164c1e04).

Sandbox executions of the parent CastleBot sample indicate that the same affiliate may have dropped a StealC payload with a C2 server at "http://107.158.128[.]105/c91252f9ab114f26.php" during the campaign; however, X-Force was not able to retrieve a sample. 

Both campaigns use the CastleBot campaign ID "81a16c72f9c9f4ea94d68b609c78f72d4a8725e7b8f6949b12d8871b6c6843e3".

Additionally, X-Force is tracking multiple CastleBot campaigns delivering various infostealers. The malware supports multiple download tasks for any campaign, which will result in the deployment of multiple payloads on the same client. The executable AMD_Chipset_DriverOnly_DCH_AMD_Z_V1.2.0.105_20238.exe (e6aab1b6a150ee3cbc721ac2575c57309f307f69cd1b478d494c25cde0baaf85) loads the embedded CastleBot core payload (b45cce4ede6ffb7b6f28f75a0cbb60e65592840d98dcb63155b9fa0324a88be2 ) from its resource and executes it. It's C2 server's settings endpoint is located at

which was found to transmit a total of three separate tasks in a single C2 message, each deploying a different payload:

• Task ID: 0x16
• • Download URL: https[:]//google.herionhelpline[.]com/app/AcerUSBUpdate.exe
  • Payload: 03122e46a3e48141553e7567c659642b1938b2d3641432f916375c163df819c1 (Rhadamanthys)
  • Install path: None
  • Launch method: 6

• Task ID: 0x17 
• • Download URL: https[:]//google.herionhelpline[.]com/app/light1_v5_signed.html
  • Payload: 12de997634859d1f93273e552dec855bfae440dcf11159ada19ca0ae13d53dff (Remcos)
  • Install path: %ProgramData%\AmazonApp\AmazonWebServiceUpdate.exe
  • Launch method: 1

• Task ID: 0x18
• • https[:]//google.herionhelpline[.]com/app/SlackUpdateWeb.html
  • Payload: c8f95f436c1f618a8ef5c490555c6a1380d018f44e1644837f19cb71f6584a8a (DeerStealer)
  • Install path: %AppData%\SlackUpdate\SlackServiceUpdate.exe
  • Launch method: 1

X-Force further discovered campaigns deploying SecTopRAT (aka ArechClient), HijackLoader (aka Shadowladder) and MonsterV2 (aka Aurotun Stealer). 

SecTopRAT and HijackLoader:

• GlobalProtect-win-6.3.zip with executable sideloading msvcp140.dll (8bf93cef46fda2bdb9d2a426fbcd35ffedea9ed9bd97bf78cc51282bd1fb2095)
• CastleBot C2 server: http[:]//107.158.128[.]45/service/settings/81a16c72f9c9f4ea94d68b609c78f72d4a8725e7b8f6949b12d8871b6c6843e3
• Payload hosted at http[:]//107.158.128[.]45/service/download/Exchanger32.zip (4834bc71fc5d3729ad5280e44a13e9627e3a82fd4db1bb992fa8ae52602825c6)

MonsterV2:

• libssl-1_1.dll (53dddae886017fbfbb43ef236996b9a4d9fb670833dfa0c3eac982815dc8d2a5) DLL-sideloaded, reflectively injects CastleBot stager
• CastleBot C2 server: http[:]//107.158.128[.]45/service/settings/8306a6b35d4be6de72be58860791e3644468fd67f675e4045a246dd27fa5692c
• Payload hosted at http[:]//107.158.128[.]45/service/download/CCver_Setup.exe (ab725f5ab19eec691b66c37c715abd0e9ab44556708094a911b84987d700aa62)

CastleBot is the latest evidence of a shift in the initial infection vectors of the cyber crime threat landscape. Backdoors and MaaS frameworks are increasingly distributed through fake websites as part of trojanized software or via the ClickFix technique. Within a few short months since observing an increase in CastleBot activity, the developers have already added several new features and will likely attempt to keep up with adapting EDR and network security solutions. Current activity suggests multiple affiliates making use of CastleBot to deploy both infostealers and backdoors, which may lead to high-impact ransomware incidents.

Defenders are advised to remain vigilant with the techniques mentioned in this report and take the appropriate actions to mitigate the risk of a CastleBot infection.

• Ensure EDR software and associated security controls are up to date
• Train users to exercise extreme caution when downloading software and refrain from installing unsanctioned or unverified software
• Implement multi-factor authentication and monitor for leaked enterprise credentials
• Set up alerts or consider blocking outgoing HTTP (non-HTTPS) connections, and URLs containing IP addresses in particular

IBM X-Force Premier Threat Intelligence is now integrated with OpenCTI by Filigran, delivering actionable threat intelligence about this threat activity and more. Access insights on threat actors, malware, and industry risks. Install the X-Force OpenCTI Connector to enhance detection and response, strengthening your cybersecurity with IBM X-Force’s expertise. Get a 30-Day X-Force Premier Threat Intelligence trial today!