Full Report
CitrixBleed 2 exploitation started mid-June — how to spot itCitrixBleed 2 — CVE-2025–5777 — has been under active exploitation to hijack Netscaler sessions, bypassing MFA, globally for a month.I wrote this about the vulnerability back on June 24th, encouraging orgs to patch as soon as possible:CitrixBleed 2: Electric Boogaloo — CVE-2025–5777At the time, I noted the similarities to CitrixBleed, and noted that although Citrix say exploitation has not been seen in the wild, during CitrixBleed they said the same thing — and were wrong shortly after. Here we go again.Since publishing that post, they put out a blog with some, uhm, interesting wording, for example:CVE-2023–4966 was CitrixBleed. They also wrote:When Citrix wrote this blog, exploitation of their customers was already happening. Although they said to contact for IOCs, that was a reference to CVE-2025–6543 — they provided no technical details to find CVE-2025–5777 exploitation.The problem here? The impact is exactly the same. The NSC_AAAC token is visible in memory:CitrixBleed 2 exploitation via Horizon3.aiThe result is attackers can use the vulnerability — by spraying the doAuthentication.do endpoint — to find valid cookies to join any Netscaler session. From there, they can — for example — establish Citrix VDE desktop sessions, or hijack active Netscaler admin sessions.Even without NSC_AAAC cookies, the RAM exposed contains other sensitive information.Not only is this possible, but it’s already happening. It’s the same situation as CitrixBleed from October 2023, so here we are again.GreyNoise are currently running a retrospective hunt on their honeypot network, and so far see activity spanning back to July 1st — this is before any public technical details on the vulnerability dropped:get on mastodonThey are currently hunting further back in their telemetry — I expect them to move that date backwards. In fact, Greynoise’s (rather excellent) honeypot telemetry now shows attempts dating back to June 23rd — 3 days later, Citrix said there was no evidence of exploitation.Working with various orgs, I can see exploitation spanning back to mid-June. Example attacker IPs:64.176.50.109139.162.47.19438.154.237.10038.180.148.215102.129.235.108121.237.80.24145.135.232.2This IP list isn’t exhaustive — more will be published here as attacks are ongoing:https://viz.greynoise.io/query/tags:%22CitrixBleed%202%20CVE-2025-5777%20Attempt%22%20last_seen:90dHow to hunt for exploitation before patchingHunting for this is a multi-stage approach:(Enhanced Netscaler logging settings dependent) If you have Netscaler web access logs in a SIEM, look for an excessive number of requests to a URI including “doAuthentication.do” — each attempt leaks 126 bytes of data, so the threat actor will likely send thousands of requests in a day to find what they’re looking for. Legit requests are mixed in, so you’re looking for outliers in terms of volume. SIEM search term examples: *POST*doAuthentication*What the attack path looks like — yes, specifying just ‘login’ gets you RAM no the right hand side in the “InitialValue” field:creds to WatchTowr(Enhanced Netscaler logging settings dependent) In Netscaler web access logs, requests to doAuthentication.do with “Content-Length: 5” in the headers. This length is optional and can of course be altered — but the activity through June had this header and when combined with a POST request, is a very good indicator of exploitation.(Enhanced Netscaler logging settings dependent) Lines with *LOGOFF* and user = “*#*” (i.e. # symbol in the username) in Netscaler logs. RAM is played into the wrong field — so the User field is filled with junk if a high enough level of logging is enabled, you will see a mix of binary and ASCII strings in the logs. If you see this, invoke incident response.POST requests to doAuthentication and GetUserName from attacker IPs, replaying the NSC_AAAC cookie, to verify it works.Many of the steps from CitrixBleed work again — for example, look for Netscaler sessions where the source IP and the client IP mismatch — the source IP will be attacker IP and the client IP will be original session IP. This is abnormal and suggests session hijacking risk — if combined with the other bullet points, it is most likely a compromised session.Example of session hijackingTechnical readingCVE-2025-5777: CitrixBleed 2 Exploit Deep Dive by Horizon3.aiHow Much More Must We Bleed? - Citrix NetScaler Memory Disclosure (CitrixBleed 2 CVE-2025-5777)Vendor response not good enoughBoth the Horizon and the Watchtowr blogs point this out, but I’ll be a bit less diplomatic — Citrix are failing customers here. By providing no technical details at all (and also mistakenly saying in the original CVE it applied to the Netscaler Management Interface), customers have been left vulnerable to attack with absolutely no clue how to check for prior exploitation. This also happened with CitrixBleed.In reality exploitation started soon after the patch release, so providing no technical details didn’t slow exploitation — it gave attackers a head start and left customers with a false sense of security that simply applying patches resolved the problem. Had they been given, for example, a clue about looking for a large volume of doAuthentication requests, they could have checked logs and looked at WAF rules (for example, doAuthentication requests missing the correct headers — despite what the Netscaler blog say,s this is possible). This didn’t happen, and now likely a large number of organisations will again be invoking incident response, under two years since CitrixBleed.Who has been exploiting this?One of the IP addresses executing attacks in mid June has prior been linked to the RansomHub ransomware group by CISA last year — this IP has been observed dumping memory and replaying session cookies to validate them. It is currently unknown to me if the other IP addresses overlap (i.e. same threat actor) — however popular providers such as Vultr and Linode are in use. A report in ReliaQuest of suspected exploitation suggests tooling often used by e-crime groups involved in ransomware:CVE-2025-5777: Citrix Bleed 2 Opens Old WoundsHow is worldwide patching going?I am tracking patching here: https://github.com/GossiTheDog/scanning/blob/main/CVE-2025-5777-CitrixBleed2-ElectricBoogaloo-patching.txtAlmost a month in, 24% of orgs still hadn’t applied patches, as of Monday. This included some of the world’s biggest companies (and the NSA). I’ll update the view over time.Even if you did already patch, unless you patched extremely early, you probably need to check for signs of exploitation.More updatesI’m on Mastodon and BlueSky:Kevin Beaumont (@doublepulsar.com)CitrixBleed 2 exploitation started mid-June — how to spot it was originally published in DoublePulsar on Medium, where people are continuing the conversation by highlighting and responding to this story.
Analysis Summary
# Vulnerability: CitrixBleed 2 (Memory Disclosure Leading to Session Hijacking)
## CVE Details
- CVE ID: CVE-2025-5777
- CVSS Score: Not explicitly stated, but implied High due to MFA bypass and session hijacking capabilities, similar to CVE-2023-4966 (CitrixBleed).
- CWE: Not explicitly stated.
## Affected Systems
- Products: Citrix NetScaler (Implied, as exploitation targets Netscaler sessions).
- Versions: Unspecified, but any version vulnerable to memory disclosure leading to session token exposure.
- Configurations: Any configuration utilizing NetScaler that is subject to memory disclosure flaws.
## Vulnerability Description
CVE-2025-5777 is a memory disclosure vulnerability in Citrix NetScaler (referred to as CitrixBleed 2) allowing remote attackers to view sensitive information from memory. This exposure includes the session token `NSC_AAAC`. Attackers leverage this by sending requests to the `doAuthentication.do` endpoint, which leaks memory containing valid session cookies. These cookies can then be used to hijack active NetScaler sessions, including VDE desktop sessions or administrative sessions, effectively bypassing Multi-Factor Authentication (MFA).
## Exploitation
- Status: Exploited in the wild (Active exploitation observed since mid-June).
- Complexity: Low (Implied, as it involves spraying an endpoint to extract tokens).
- Attack Vector: Network (Remote).
## Impact
- Confidentiality: High (Exposure of session tokens like `NSC_AAAC` and other sensitive memory contents).
- Integrity: High (Ability to hijack active sessions, including administrative sessions).
- Availability: Medium (Potential disruption through session takeover, though the primary impact is authentication bypass).
## Remediation
### Patches
- Specific patch information is not provided in this summary, but the context indicates that patching is necessary to resolve the underlying vulnerability (similar to CVE-2023-4966). Organizations are urged to patch immediately. (Note: Vendor reporting on technical details was insufficient).
### Workarounds
- **Log Monitoring/Hunting:** Focus on identifying prior exploitation activity detailed below.
- **WAF Rules:** Review Web Application Firewall (WAF) rules, especially concerning the `doAuthentication.do` endpoint, to ensure proper header enforcement, as exploitation attempts might deviate from expected legitimate traffic patterns.
## Detection
Detection focuses on identifying the exploitation attempts based on memory spraying and session hijacking post-exploitation activity:
**Indicators of Compromise (IOCs) - Attacker IPs:**
* 64.176.50.109
* 139.162.47.194
* 38.154.237.100
* 38.180.148.215
* 102.129.235.108
* 121.237.80.241
* 45.135.232.2
**Detection Methods (Requires Enhanced NetScaler Logging):**
1. **Excessive `doAuthentication.do` Requests:** Search NetScaler web access logs for an unusually high volume of requests toURIs containing `doAuthentication.do` (attackers send thousands of requests to find valid cookies).
* *SIEM Search Example:* `*POST*doAuthentication*`
2. **Specific Request Headers:** Look for POST requests to `doAuthentication.do` explicitly using a specific header signature observed during initial attacks:
* `Content-Length: 5`
3. **Abnormal Logoff Activity:** Search logs for lines containing `*LOGOFF*` where the `user = “*#*”` (a hash symbol in the username field), indicating memory data being written to the wrong log field. This implies successful data dumping.
4. **Session Hijacking Verification:** Look for active sessions in logs where the **Source IP** (attacker IP) and the **Client IP** (original authenticated user IP) do **NOT** match.
## References
- Technical Reading: `Horizon3.ai` technical deep dive.
- Technical Reading: `WatchTowr` analysis ("How Much More Must We Bleed? - Citrix NetScaler Memory Disclosure (CitrixBleed 2 CVE-2025-5777)").
- IOC Hunting Reference: GreyNoise telemetry tagging for CVE-2025-5777 attempts: `https://viz.greynoise.io/query/tags:%22CitrixBleed%202%20CVE-2025-5777%20Attempt%22%20last_seen:90d` (Defanged Link)
- Patching Status Tracking: `https://github.com/GossiTheDog/scanning/blob/main/CVE-2025-5777-CitrixBleed2-ElectricBoogaloo-patching.txt` (Defanged Link)