CitrixBleed 2 (CVE-2025-5777): The Seven-Step Playbook From NetScaler Memory Leak to DragonForce Ransomware in Under an Hour

Sources: Huntress Tactical Response — primary research blog “CitrixBleed 2: 7 Steps to DragonForce Ransomware” · CybersecurityNews · GBHackers · Cyberpress · IT Security Guru · Cybersecurity Dive · The Hacker News | CVE: CVE-2025-5777 | Name: CitrixBleed 2 | CVSS: 9.3 (Critical) | Affected products: Citrix NetScaler ADC and NetScaler Gateway configured as Gateway or AAA virtual server | Vulnerability class: Memory overread (heap) via malformed pre-auth login request — leaks active session tokens | MFA bypassed: Yes — replaying a stolen token skips authentication entirely | Intrusions investigated: 6 across unrelated organizations, H1 2026 | Ransomware deployed: DragonForce (most advanced case) | Time to ransomware from initial access: Under one hour (fastest observed) | Threat actor assessment: Single highly successful Initial Access Broker (IAB) — productized runbook | Sophos cluster name: STAC3725 | Critical note: Harvested tokens survive a patch — terminate all sessions immediately

5,937 failed logins in five hours. Not password guessing. Leaked heap memory. The session was already stolen before a single success appeared in the logs.

Between January and June 2026, Huntress’s Tactical Response unit investigated six separate intrusions at unrelated organizations. All six began the same way. All six followed the same seven steps. All six used the same privilege-escalation technique, created accounts with the same naming patterns, and deployed the same remote-access tools. In the most advanced case, the operation ended with DragonForce ransomware deployed in under an hour from initial access. Huntress calls it a productized runbook — the fingerprint of a single, highly successful Initial Access Broker who has packaged CitrixBleed 2 into a repeatable, scalable attack pipeline.

The vulnerability at the entry point is CVE-2025-5777, a memory-overread weakness in Citrix NetScaler ADC and Gateway that Citrix disclosed and patched in 2025. It is the successor to the original CitrixBleed (CVE-2023-4966) — same product, same attack class, same operational consequence: a malformed pre-authentication login request causes the NetScaler to return fragments of heap memory in its response, and those fragments can contain active session tokens belonging to legitimately authenticated users. An attacker who collects enough heap fragments can extract a valid session token and replay it — authenticating as that user without knowing their password, without triggering any authentication challenge, and without completing any MFA step. The session was already authenticated. The attacker just inherited it.

What Huntress found in every case was not the fingerprint of opportunistic attackers probing for weak passwords. It was the fingerprint of a structured memory-harvesting operation. The earliest indicator was not conventional password spraying. NetScaler logs contained thousands of AAA LOGIN_FAILED events with unprintable binary values in the username field. Huntress determined that these values represented leaked heap memory rather than failed username guesses. In one incident, Huntress counted nearly 5,937 AAA LOGIN_FAILED events from attacker-controlled IP addresses over roughly five hours. Those were not login attempts. They were memory harvesting requests — the attacker sending malformed requests at volume and sifting the binary responses for usable session cookies.

How CitrixBleed 2 works — and why MFA offers no protection

The technical mechanism of CVE-2025-5777 is directly analogous to the original CitrixBleed (CVE-2023-4966) that DataWater covered in the Verizon DBIR 2026 analysis. CitrixBleed 2 is a memory-overread weakness in NetScaler systems configured as Gateway or AAA virtual servers. It is reachable before authentication through login endpoints, including pudoAuthentication.do, when a POST request contains an empty login parameter.

When the NetScaler processes this malformed request, it reads past the end of the intended memory buffer and returns heap contents in the response. By sending large numbers of requests, attackers can collect heap-memory fragments and search them for active session cookies or tokens. NetScaler’s in-memory session store holds the session tokens of currently authenticated users — users who have already completed their password challenge and MFA step and have an active VPN or web session. The tokens in heap memory are valid, live credentials for active sessions.

Once an attacker has a valid token, they replay it against the NetScaler. Replaying a stolen token makes multi-factor authentication ineffective because the session was already verified. The attacker did not log in — they inherited a session that a legitimate user had already authenticated. The MFA check happened before the token was issued. Replaying the token requires no password, no push notification, no TOTP code, no hardware key. The attacker is, from the NetScaler’s perspective, the legitimate user continuing an existing session.

Huntress identified no corresponding successful authentication event for the attacker, providing strong evidence that the session was stolen and replayed. The strongest evidence of session hijacking appeared when a legitimate user authenticated using LDAP and MFA from a known IP address — and then the same session token subsequently appeared being used from a completely different, attacker-controlled IP address, with no new authentication event in between.

The seven-step playbook — documented step by step

Step 1 — Memory harvest at scale

The attacker sends thousands of malformed POST requests to the NetScaler’s authentication endpoint with an empty login parameter. Each response leaks fragments of heap memory. Over several hours, the attacker accumulates enough fragments to identify and extract valid session tokens. The only forensic trace at this stage: thousands of AAA LOGIN_FAILED log entries with binary garbage in the username field — easily missed if logs are not being actively monitored and forwarded to a SIEM.

Step 2 — Session token replay, MFA bypassed

The attacker replays a harvested token against the NetScaler, establishing an authenticated session as a legitimate user. No password needed. No MFA challenge issued. The NetScaler has no mechanism to distinguish a legitimately continued session from a replayed stolen token — both present the same valid credential.

Step 3 — SYSTEM escalation via registry-symlink and AppMgmt

Inside the environment, the attacker deploys a portable Windows privilege-escalation tool. The tool abused a registry symbolic link, forced a Group Policy update, and started the Application Management service, AppMgmt. This is a known Windows LPE technique that exploits the interaction between Group Policy processing and the Application Management service to execute code as SYSTEM. The tool is portable — it runs from a single binary with no installation required.

Step 4 — Rogue local admin account creation

From the SYSTEM context, the attacker creates a local administrator account. Huntress noted consistent naming patterns across all six victims — the rogue accounts used similar names, pointing to the same IAB operator running the same script. In at least one case, the account was named to superficially resemble a legitimate Citrix service account, reducing the likelihood of immediate detection by a security analyst reviewing the account list.

Step 5 — Registry cleanup

It subsequently created a local administrator account and cleaned up registry changes, making later investigation more difficult. The cleanup step removes the registry symbolic link artifacts used in the escalation — reducing the forensic trail and specifically targeting the evidence a responder would look for when investigating the LPE technique used.

Step 6 — Persistence via ScreenConnect and Zoho Assist

The attacker establishes persistent remote access using legitimate commercial remote-access tools: ScreenConnect (now ConnectWise ScreenConnect) and Zoho Assist. Both are widely used by IT teams for legitimate remote support — their presence does not automatically trigger EDR alerts, and their traffic is often explicitly allowed through firewall rules. The same attacker-controlled hostnames recurred across victims — the same ScreenConnect and Zoho Assist server infrastructure served multiple intrusions, another signature of a single IAB operating a productized runbook rather than independent actors.

Step 7 — DragonForce ransomware (most advanced case)

In the most advanced confirmed case, the IAB handed off or directly deployed DragonForce ransomware. In the incident that progressed to ransomware, the speed the adversary operated with was their singular advantage — ransomware was deployed almost immediately following the execution of the preceding steps. The total time from initial CitrixBleed 2 exploitation to ransomware deployment was under one hour. Huntress assesses with high confidence that an Initial Access Broker is weaponizing CVE-2025-5777 to gain access to Citrix environments, ultimately with the goal of deploying ransomware. In their observations, the ransomware deployed was DragonForce, but public and private reporting finds indicators of other ransomware groups using this cluster as well.

The IAB model — why the same playbook appears at unrelated victims

The most operationally significant finding in Huntress’s research is not any individual intrusion — it is the consistency across all six. Same privilege-escalation technique. Same rogue account naming patterns. Same attacker-controlled hostnames for ScreenConnect and Zoho Assist. Same seven steps in the same order. Huntress considers the activity most likely to represent a single, highly successful IAB rather than a DragonForce-specific affiliate.

An Initial Access Broker operates by systematically compromising networks at scale and selling that access to downstream buyers — ransomware affiliates, espionage operators, data theft actors — who then complete the attack for their own purposes. The IAB’s product is the foothold. DragonForce ransomware is what one specific buyer did with it. Other buyers — potentially deploying different ransomware or pursuing different objectives — are indicated in private threat intelligence reporting that Huntress references without detailing publicly.

The implication for defenders: the intrusions Huntress investigated were so mechanically similar — same privilege-escalation technique, same rogue account names, even the same attacker-controlled hostnames recurring across victims — that they point to a productised runbook rather than opportunistic, independent attacks. This means indicators of compromise from one victim have high fidelity predictive value for other potential victims — and it means organizations that see the memory-harvest signature in their NetScaler logs should treat the investigation with the urgency of an active ransomware precursor, not a routine auth anomaly.

The critical remediation detail most organizations will miss

Patching CVE-2025-5777 stops new session tokens from being harvested. It does not invalidate session tokens that were already harvested before the patch was applied. A token stolen last week remains valid today — even on a fully patched NetScaler — until it is explicitly terminated. This is the operational gap that creates continued exposure after patching and is specifically called out by Huntress as the most commonly missed remediation step.

Session termination commands (NetScaler CLI):

# Terminate all active ICA (Citrix Virtual Apps/Desktops) connections
kill icaconnection -all

# Terminate all active AAA (authentication) sessions
kill aaa session -all

# Terminate all active NetScaler Gateway sessions  
kill icaconnection -gatewayconnection

# Verify no sessions remain
show aaa session
show icaconnection

# After termination, force all users to re-authenticate
# This invalidates any stolen tokens that were in active use

Additionally: forward NetScaler logs to a SIEM or long-term retention platform before investigating. NetScaler on-device logs rotate on short cycles — the evidence of the memory-harvesting phase (the thousands of AAA LOGIN_FAILED events with binary username data) will be overwritten if logs are not preserved externally. If you suspect exploitation, preserve logs first, then investigate.

IOC signatures to hunt for right now

• NetScaler AAA LOGIN_FAILED events with binary/unprintable data in username field — this is the memory-harvest signature. Normal failed logins have readable (if wrong) usernames. Memory-harvest requests have binary heap content.
• High volume of pre-auth requests to pudoAuthentication.do from a single or small cluster of IP addresses — particularly if the requests occur in bursts over several hours.
• Session activity from an IP address inconsistent with the legitimate user’s known locations — particularly immediately following legitimate authentication from a known IP (the token-replay pattern).
• New local administrator accounts — particularly accounts named to resemble Citrix service accounts or using the naming patterns Huntress documented in their full IOC list at huntress.com/blog/citrixbleed-2-dragonforce-ransomware.
• Unexpected ScreenConnect or Zoho Assist installations — particularly instances connecting to unfamiliar server hostnames not in your known-good remote-access inventory.
• AppMgmt service starts correlated with Group Policy updates — this is the registry-symlink LPE signature.

CitrixBleed 2 in the context of 2026’s network perimeter crisis

CitrixBleed 2 joins FortiBleed, Palo Alto PAN-OS CVE-2026-0257, and Cisco SD-WAN as the fourth major network perimeter credential-bypass campaign DataWater has documented in 2026. The pattern is consistent across all four: an internet-facing network security or access appliance, a vulnerability that bypasses authentication — either directly or via credential theft — and a downstream ransomware or espionage payload.

The specific CitrixBleed 2 detail that distinguishes it from FortiBleed is the speed: FortiBleed operated slowly over months, building a credential database. CitrixBleed 2’s IAB operates in under an hour from initial access to ransomware. The attack surface is the same category — internet-facing network access infrastructure. The operational tempo is completely different. Defenders who have built incident response playbooks around FortiBleed’s slow credential accumulation model need a separate playbook for the CitrixBleed 2 timeline, where the window between “first anomalous log event” and “ransomware executing” is measured in minutes.

Sources and further reading

• Huntress Tactical Response — CitrixBleed 2: 7 Steps to DragonForce Ransomware (Primary Research)
• CybersecurityNews — Hackers Can Go From CitrixBleed 2 Exploitation to Ransomware in Under an Hour
• GBHackers — Hackers Exploit CitrixBleed 2 to Hijack MFA-Protected Sessions and Deploy DragonForce Ransomware
• Cyberpress — Hackers Abuse CitrixBleed 2 to Steal Session Tokens and Bypass MFA Protections
• Cybersecurity Dive — Initial Access Broker Linked to Weaponization of CitrixBleed 2 Flaw
• IT Security Guru — CitrixBleed 2 Exploited in Repeatable Attack Chain Culminating in DragonForce Ransomware
• The Hacker News — Ransomware Groups Turn to Citrix Bleed 2, BYOVD, and Supply Chain Credentials

DataWater publishes daily cybersecurity intelligence for enterprise and government security leaders. Article #41 — July 13, 2026. Previous: JADEPUFFER — First AI Agent Ransomware (July 9) · Bad Epoll CVE-2026-46242 (July 5) · DuneSlide Cursor IDE CVSS 9.8 (July 2). Browse the full threat brief archive →