Anomali Cyber Watch: CastleStealer & npm SDK Supply Chain Risks

CastleStealer is a C#-based information-stealing malware first identified in April 2026, when a ClickFix campaign used fake background-removal websites to deliver it via finger.exe and a multi-stage Python-based loader, CastleLoader, alongside NetSupport remote access trojan (RAT). A second campaign, active in April and May 2026, used malicious Google Ads impersonating Node.js to deliver a new loader, OXLOADER, which abused legitimate cloud storage to evade reputation filtering, performed six anti-VM and language checks including emulation, CPU count, RAM, display refresh rate, geographic region, and system language, and delivered CastleStealer entirely in memory. Commonwealth of Independent States (CIS)-region and Russian-language exclusions across both campaigns suggest a financially motivated, Russian-speaking threat actor. Once running, CastleStealer exits on Russian-locale systems, beacons host details to command-and-control (C2) infrastructure, and collects credentials, cookies, and session data from Chromium browsers, Firefox, Discord, Telegram, and Steam, using the Windows Restart Manager API to access locked files. Newer samples add an IElevator COM interface bypass for app-bound encryption absent from earlier builds, remote shell functionality allowing operators to execute commands and deploy additional payloads, and Advanced Encryption Standard (AES)-encrypted exfiltration over raw TCP in small packets rather than a single archive. CastleStealer deletes itself using a ping-delay technique.

Source

Analyst Comment

CastleStealer’s development trajectory is the primary intelligence signal here. The addition of an IElevator-based app-bound encryption bypass, a technique shared with other modern infostealers and publicly disclosed in late 2024, suggests the operators are actively monitoring other active infostealer families and adopting proven methods to close documented limitations in their own tooling. Its adoption within months of first appearance reflects a responsive and operationally disciplined approach to development. OXLOADER’s sandbox evasion checks require a minimum of three CPUs, three gigabytes of RAM, a display refresh rate above 20 Hz, and passing an emulation test that many sandboxes fail; organizations relying heavily on dynamic analysis should not treat a clean detonation result as a reliable all-clear. Both campaigns abused legitimate services for payload delivery, whether a cloud storage platform with a clean domain history or a native Windows binary, to bypass controls that rely on reputation or file-based detection. A confirmed CastleStealer infection should not be treated as a contained credential-harvest event; the remote shell capability means an operator may have introduced additional payloads or established alternate persistence before detection, and the appropriate response posture is a persistent access investigation rather than credential resets and a reimage alone. CastleStealer has not reached widespread adoption, but defensive weight sits on detection and response rather than user awareness alone.

PoeLLM is a financially motivated malware campaign, tracked as Canto Incognito, that has infected more than 3,400 servers since April 2026. It targets internet-facing artificial intelligence (AI) and large language model (LLM) services, specifically LiteLLM and Ollama, alongside open-source tools Gotenberg and Gitea, with possible targeting of Ivanti Sentry appliances. CVE-2026-42271, a command injection flaw in LiteLLM, is assessed as the likely exploitation path, with vulnerable servers forced to download and execute the malware. Once installed, it deploys XMRig and Iron cryptocurrency miners connecting to Kryptex, a Russian mining service, while repurposing infected hosts as scanners and exploit servers to expand the victim pool. The malware derives its command-and-control (C2) address by fetching a poem from a GitHub repository, extracting four keywords, and converting them to IP octets via a hardcoded dictionary. The poem was updated 11 times since April 13, 2026, each change redirecting infected hosts to a new C2 server. Infections are concentrated in the US and Western Europe, peaking at nearly 2,200 affected servers in mid-June with around 800 active per day. Researchers attribute the campaign with moderate confidence to an Italian-speaking threat actor. The GitHub repository has since been taken down, disrupting C2 operations.

Source

Analyst Comment

The entry point in this campaign was not novel exploitation but internet-exposed services running known vulnerabilities outside normal patch and monitoring cycles. As AI tooling spreads across enterprise environments, security operations are not consistently tracking or protecting it at the same level as traditional infrastructure. Defenders should audit internet-facing AI and open-source services, verify that LiteLLM is upgraded to version 1.83.7 or later to address CVE-2026-42271, and confirm that Starlette is upgraded to version 1.0.1 or later to address CVE-2026-48710. Both are required: when chained, these vulnerabilities enable unauthenticated remote code execution against vulnerable LiteLLM deployments, and patching only one leaves the full attack path open. These tools should also fall within existing patch management and attack surface management programs. Network logs should be checked against the published IOCs. The C2 mechanism warrants specific attention: by deriving server addresses from content hosted on GitHub, the actor rotated C2 infrastructure 11 times without provisioning new servers or registering new domains for each rotation, making IOC-based blocking of C2 addresses significantly less reliable as a standalone defensive control. Assessed: servers running AI workloads are likely a higher-value cryptomining target than conventional infrastructure due to their overall compute power, and the operational and financial impact of compromise on these systems may exceed what a typical cryptomining incident would suggest.

Attackers using a compromised Tensorlake repository administrator account injected a malicious build of the Shai-Hulud worm into version 0.5.144 of its software development kit (SDK), an npm package with approximately 12,000 weekly downloads. The attacker committed the payload via GitHub’s browser interface and triggered the project’s release workflow, giving the malicious version the appearance of a legitimate signed release. A preinstall hook executes the payload on the developer’s machine at install time, outside Tensorlake’s sandbox. The payload collects npm and GitHub tokens, AWS credentials, HashiCorp Vault and Kubernetes service-account tokens, SSH keys, cryptocurrency wallet files, and browser passwords, then exfiltrates the data to command and control (C2) infrastructure at iseekaigogo[.]com, using an Ethereum smart contract to resolve the C2 address and resist takedown. A persistent monitor watches stolen GitHub tokens and deletes the user’s home directory if a token is revoked, but only for accounts with no organizational affiliations; the monitor must be removed before any credential rotation. The worm attempts self-propagation via stolen npm tokens. Automated tooling flagged the package within 11 minutes of publication; npm removed it and Tensorlake released 0.5.145.

Source

Analyst Comment

This incident is more accurately framed as a near-miss than a rapid response success. Automated detection flagged the package within 11 minutes of publication, but any developer who ran npm install before that window closed was fully compromised regardless of how quickly the package was subsequently pulled. The affected user profile matters here: Tensorlake is AI agent infrastructure tooling, and developers building with it are likely to have npm tokens, GitHub credentials, AWS access keys, Vault tokens, and Kubernetes service-account tokens on the same machine. That is a high-value credential combination and the payload was specifically built to collect all of it. On the C2 infrastructure: blocking iseekaigogo[.]com is insufficient as a standalone measure. The malware resolves its endpoint dynamically through an Ethereum smart contract, which the attacker can update without touching the payload, meaning the known domain can be sidestepped entirely without a payload change. The organisational affiliation filter on the deletion trigger likely reflects noise reduction rather than deliberate targeting (wiping a corporate machine accelerates incident response and attracts attention, while a solo developer’s home directory is a quieter loss), though no source documents attacker intent behind this design decision and it should be treated as analyst inference. The practical implication is the same regardless of intent: removal of gh-token-monitor must precede any credential revocation on affected hosts, without exception. On attribution: analysis by OX Security indicates the RSA keys in this payload are newly seen and not present in prior Shai-Hulud variants. TeamPCP open-sourced the Shai-Hulud tooling in May 2026, meaning code and technique similarity no longer establishes actor continuity. Whether this represents TeamPCP, an affiliate, or an independent actor using the public toolkit is currently unresolved. Defenders should not assume prior Shai-Hulud detection rules provide sufficient coverage for this variant.

ASOS suffered a data breach after an attacker impersonated a trusted contact to obtain an employee’s login credentials, using them to access third-party platforms holding customer data. On October 6, 2026, the attacker pushed unauthorized messages through the official ASOS mobile app, claiming a Snowflake compromise and threatening to leak data. Snowflake confirmed on October 9 that no vulnerability in its platform was involved. Security researchers identified Simon AI, an agentic marketing platform built on Snowflake Cortex AI and publicly associated with ASOS, as potentially relevant; the threat actor told the BBC a Simon AI instance was compromised, a claim ASOS has not confirmed. Xuanye Group claimed responsibility. Group-IB linked the group’s Telegram account to prior gaming-item trading personas with no prior cyberattack history. ASOS confirmed that full names, contact details, and certain non-personal account data were exposed; payment card details and account passwords were not accessed. A data sample provided to the BBC reportedly included customers’ on-site search terms, although ASOS has not publicly confirmed those additional data categories. The UK Information Commissioner’s Office has been notified and is assessing the incident; the number of customers affected has not been disclosed and the investigation remains ongoing.

Source

Analyst Comment

The core defensive lesson centers on third-party access. ASOS confirmed stolen employee credentials were used to access multiple third-party platforms, and sources indicate the data exposure and notification capability may have involved separate services, meaning the exposure may span more than one vendor relationship. Agentic marketing and customer data platforms operate with automated, persistent access to sensitive data and outbound communication channels, and frequently sit outside standard detection coverage. Use of valid SaaS credentials can blend with legitimate activity where authentication and audit telemetry from third-party platforms is not correlated within central detection systems. Group-IB found no previous cyberattack history associated with the Xuanye Group Telegram persona, but defenders should not treat an unfamiliar identity as evidence of low capability. Valid credentials provided access to high-impact third-party services regardless of the actor’s public track record. Phishing-resistant multi-factor authentication (MFA), specifically FIDO2/WebAuthn hardware security keys, raises the bar against credential-based initial access, and that control should extend to vendor platform authentication requirements, not just internal systems. Defenders should map which third-party platforms hold access to customer data or can send communications on the organization’s behalf, and assess whether security requirements reflect the access those vendors have been granted.

Researchers identified a ClickFix campaign using compromised websites to pre-stage a Visual Basic Script (VBScript) payload in visitors’ browser caches, disguised as a PNG image. A fake CAPTCHA prompt instructs victims to open Windows Run, paste clipboard content, and press Enter. Rather than downloading the payload at that point, the command locates the pre-cached file by byte size, copies it to a temporary .vbs file with copy output and errors suppressed, and executes it via wscript.exe. This separates first-stage delivery from execution: the Run command does not itself retrieve a remote payload, removing the network event that execution-focused detections expect, while subsequent stages continue to make outbound connections. The VBScript collects host information through Windows Management Instrumentation (WMI) and retrieves a PowerShell script from attacker-controlled infrastructure with execution policy bypassed. Subsequent stages use legitimate Windows compilation tools to build .NET assemblies, load them into memory, and inject code into timeout.exe to target browser and device credentials. The payload modifies per-user PowerShell registry settings, unpacks Python using tar.exe, and establishes persistence via a scheduled task running a Python payload through pythonw.exe. Microsoft Defender Antivirus detects the malicious activity as Trojan:Win32/ClickFix and Trojan:Win32/TermFix.

Source

Analyst Comment

This campaign deliberately breaks a detection relationship most defenders rely on: the correlation between a suspicious Run command and an immediate network event. Because the VBScript is already staged locally, the pasted command carries no immediate payload download, potentially reducing visibility for detections that correlate command execution with a contemporaneous network retrieval. Network activity follows later, from PowerShell, and may not be correlated back to the original Run event depending on telemetry configuration. Defenders should pivot away from download events toward the behavioral sequence this chain produces: RunMRU registry key activity, suspicious wscript.exe and PowerShell execution, .NET compilation via csc.exe and cvtres.exe outside development contexts, code injection into timeout.exe, and scheduled task creation involving pythonw.exe. None of these individually confirm compromise, but the sequence is distinctive. User awareness also carries real weight: a CAPTCHA instructing someone to run a command is a clear signal that requires no tooling to act on. Organizations relying primarily on download-based or isolated execution detections may have reduced visibility at the initial stage, making behavioral correlation across the full chain more important for identifying activity before credential theft or further compromise.

Researchers identified two Unicode characters that bypass Chromium’s IDN display defenses, allowing lookalike domains to appear convincingly similar to legitimate addresses in Chromium-based browsers. Chromium uses two relevant display checks. The first rejects all-Cyrillic labels only when every character appears on a 28-character Latin-lookalike list (Chrome 154 and 155; a 29th committed to source but absent from those releases). Three characters currently absent defeat it: ү (U+04AF), ő (U+04E9), and ї (U+0457). The second converts hostnames to comparison strings matched against 8,462 popular websites; ő and Latin K with hook (ƙ), used in Hausa and Karai-karai, each retain a residual mark that prevents a match. Navigation-time warnings also fail: аррӏő.com is two character edits from apple.com’s comparison string, exceeding the one-edit threshold, and oƙta.com targets a four-character domain excluded from near-match checks. Sender-rendering tests on 20 proof-of-concept domains found Gmail showed all IDN addresses in Unicode and Outlook Web showed all in encoded form; neither applied lookalike-specific warnings, though delivery protections were not evaluated. October 2026 .com zone analysis identified 161,894 IDN lookalike pairs among 733,509 internationalized registrations, reflecting visual similarity rather than confirmed malicious intent.

Source

Analyst Comment

For this class of domain, the address bar and padlock are no longer reliable trust signals. A visually deceptive IDN can obtain a valid TLS certificate, as the researchers demonstrated, and render in Unicode with no browser warning, removing the cues that security awareness training teaches users to check. The researchers identified no associated CVE or comprehensive fix in the tested versions, and Chromium’s IDN protections continue to evolve. Email is likely the most immediate exposure pathway for most defenders: Gmail rendered all IDN sender domains in Unicode without lookalike-specific warnings in the researchers’ sender-rendering tests, and an attacker-controlled lookalike can pass SPF, DKIM, and DMARC when correctly configured, since each protocol authenticates domain use rather than visual similarity to a trusted brand. Where gateways evaluate the encoded sender form, tagging inbound mail from xn-- sender domains requires no browser fix. FIDO2 passkeys are among the strongest available controls against credential phishing in this scenario, as authentication is cryptographically bound to the genuine origin and will not respond to a lookalike regardless of what the address bar shows. Where DNS telemetry is available, monitoring xn-- queries adds a detection layer independent of browser display.