What is CastleStealer? CastleStealer is a C# information stealer for Windows that collects browser, application and local-file data. Newer samples also support remote commands and the execution of additional payloads.
A Fake Installer Starts the Windows Chain
A search for Node.js led one user into the delivery route documented in June. The sponsored result opened a false installation page, which supplied a batch script through Storj. Once the user ran it, an installation wizard appeared while PowerShell downloaded OXLOADER. The command used -Verb RunAs, so Windows presented a UAC elevation prompt.
That sequence needs the distinction. A request to approve elevation doesn’t demonstrate an automatic UAC bypass, and a page impersonating Node.js doesn’t establish a compromise of the project. Here, the attacker replaced the expected installer with a loader.
There was already another route into Windows. CastleStealer first appeared publicly in April 2026, through a ClickFix lure disguised as an image-background-removal service. Its verification instructions led to code execution and a Python script that ran CastleLoader. These are separate delivery chains, each reaching the same stealer family.
OXLOADER Reconstructs the Payload in Memory
The apparent application hasn’t reached normal startup when OXLOADER begins unpacking. In an inspected sample, a redirected C++ initializer transfers control to a decryption routine. Several stages rewrite code and decrypt the next region before execution continues. As a result, inspecting the original download reveals only part of the code that will run.
After checking the host, the loader copies Windows’ dui70.dll library to a temporary file with an .ocx extension. It adds an .xtext section with read, write and execute permissions, then loads this modified copy using LoadLibraryA. Shellcode from the loader’s own .reloc section moves into .xtext and runs there. A Donut-generated stage eventually loads the .NET stealer in memory.
The copied library’s familiar name is only one detail in that sequence, its contents and executable sections have changed. Memory loading also leaves the earlier activity intact. Before the final assembly runs, the chain has already downloaded an executable and modified a library on disk.
An Expected Windows Error Gates Execution
One OXLOADER test starts with a network resource that Windows should reject. The loader calls WNetAddConnection2W with that malformed resource and checks for ERROR_BAD_NAME. Getting the expected error lets the chain continue; a different result leads to a failure branch.
The test checks the host’s API behavior, which can expose an environment that returns unrealistic results. Other gates inspect CPU count, memory, display refresh rate and geography. Selected regional settings and a Russian-language configuration can also halt execution.
These details make a stopped sandbox run harder to interpret. The loader may have rejected the environment before reaching the stealer, so absence of a final payload needs context. However, the documented gates come from particular OXLOADER builds. Different delivery routes can have different checks.
App-Bound Encryption Is a Separate Boundary
Chrome’s Windows cookie protection changed with Chrome 127. App-Bound Encryption uses a privileged service to record and verify the requesting application’s identity. That adds a check beyond ordinary execution as the logged-in user, preventing another application from simply decrypting the protected data.
Newer CastleStealer samples use Chrome’s IElevator COM interface to bypass that check. Earlier samples lacked this capability. The October analysis identifies the interface and the result, but it doesn’t publish the entire procedure. Required privileges and a browser-version matrix are also absent.
For the documented delivery chain, this leaves two separate observations. The earlier OXLOADER installation requested elevation. Later stealer samples gained a browser bypass. The reports don’t show those stages together on every infected machine, and they don’t establish universal success against current Chromium releases.
Collection Opens the Door to Further Execution
Browser data is only part of CastleStealer’s collection. The malware searches Chromium and Firefox stores, messaging-application directories, Steam files and local documents. Alongside login data and cookies, it collects browser-extension storage and IndexedDB content. Consequently, the exposure can reach data held by applications as well as saved passwords.
An operator can then send a command, supply a file to execute, or give the stealer a URL for another payload. That leaves room for a second decision after the first theft, the operator can choose what runs next. The October report doesn’t identify a particular ransomware family or a confirmed downstream deployment.
This is why the entry script cannot explain the whole incident. It shows how the stealer arrived. Later commands can extend the operation beyond the original download and beyond the data already collected.
Encrypted Transfers Use Small TCP Messages
CastleStealer sends collected data in smaller transmissions over raw TCP, using AES encryption. The described packet carries a four-byte size field, an initialization vector and encrypted data. This gives the application its own message format rather than a single archive upload.
Smaller transfers may avoid the conspicuous spike associated with uploading one large bundle. However, that is an assessment of the design’s possible benefit, not proof that network monitoring cannot detect it. Neither AES nor TCP alone distinguishes malicious traffic.
After completing its activity, the malware uses a ping-delay technique to delete itself. That cleanup can remove the executable, but it does not establish that stolen data or previously launched payloads disappear with it.
Conclusion: The Stealer No Longer Stops at Theft
CastleStealer demonstrates how quickly an information stealer can evolve into a broader endpoint threat. What began as malware focused on collecting browser credentials and application data now includes techniques for bypassing browser protections, executing remote commands, and delivering additional payloads.
The attack begins by exploiting trust in familiar software installation and verification workflows. Fake Node.js advertisements and ClickFix pages persuade users to execute scripts that introduce malicious loaders. OXLOADER then uses multiple decryption stages, sandbox checks, modified Windows libraries, and in-memory execution to deliver CastleStealer while complicating conventional analysis.
The newer capabilities make the consequences more serious. By abusing Chrome’s IElevator COM interface, CastleStealer can access browser data protected by App-Bound Encryption in the analyzed samples. Its remote command functionality also allows operators to execute commands, launch supplied files, or download additional malware. What starts as credential theft can therefore become a platform for further compromise.
Why This Threat Matters
- Trusted installation workflows become malware delivery channels. Fake developer-tool downloads and ClickFix instructions turn ordinary user actions into executable attack paths.
- Multiple execution stages complicate detection. OXLOADER combines self-decryption, anti-analysis checks, modified libraries, and memory-based payload loading.
- Browser encryption is not an absolute endpoint boundary. Newer CastleStealer variants demonstrate techniques for accessing data protected by Chrome’s App-Bound Encryption.
- Remote commands extend the attacker’s options. Operators can execute additional payloads after the initial compromise rather than ending the operation with credential collection.
- Encrypted exfiltration can be difficult to distinguish by volume alone. Smaller AES-encrypted TCP transmissions may avoid obvious bulk-transfer patterns without making the traffic inherently undetectable.
- Self-deletion does not establish recovery. Removing the original executable does not invalidate stolen credentials or remove additional payloads that may have been launched.
Where Defensive Control Must Operate
Xcitium Advanced EDR, powered by Xcitium’s patented Zero-Dwell platform, addresses the execution chain from malicious scripts and OXLOADER to in-memory payloads, suspicious browser access, and remote command activity. Execution Governance adds an earlier control point by restricting what unknown code can execute, modify, or access before additional payloads establish themselves.
Xcitium Cyber Awareness Education helps employees recognize deceptive software downloads and ClickFix instructions, while Phishing Simulation tests their ability to resist fake installation and verification workflows under realistic conditions.
Stop the Loader Before Theft Becomes Remote Access
Defenders must address both the initial execution and the capabilities that follow. Verify software distribution sources, restrict unknown scripts and binaries, investigate suspicious memory execution, and monitor unexpected command activity. When CastleStealer is discovered, recovery should extend beyond removing the executable to reviewing exposed browser credentials, sessions, and evidence of additional payload execution.
