CitrixBleed 2: Honeypot Analysis

In June 2025, the cybersecurity community was alerted to a critical vulnerability dubbed CVE-2025-5777, also known as "CitrixBleed 2." This severe flaw impacts Citrix NetScaler ADC and Gateway appliances, specifically targeting authentication mechanisms via the /p/u/doAuthentication.do endpoint. Due to improper input validation, attackers can exploit this vulnerability to remotely leak sensitive memory contents without any authentication, compromising critical data such as session tokens, user credentials, and system level secrets. The simplicity of exploitation and its widespread exposure on VPN and AAA virtual servers have quickly elevated CVE-2025-5777 to a top tier threat, prompting urgent advisories from both Citrix and cybersecurity authorities like CISA. This blog post provides an in depth analysis of the vulnerability, detailing its exploitation mechanics, potential impacts, detection strategies, and essential mitigation steps organizations must implement immediately to safeguard their infrastructure.

[•] Vulnerability Overview

Identifier: CVE‑2025‑5777 (“CitrixBleed 2”)
Disclosure Date: June 17, 2025 via Citrix security bulletin CTX693420; scope updated June 23, 2025 (per Citrix via NVD)
Nickname: "CitrixBleed 2" (inspired by CitrixBleed CVE‑2023‑4966)
Severity: CVSS v4.0 9.3 (Critical)

[•] Impact

• Pre‑authentication remote memory disclosure in Citrix NetScaler ADC and Gateway appliances.

• Leaked memory fragments may include session tokens (even nsroot), credentials in plaintext, authentication cookies, and other sensitive data.

• Attackers can hijack authenticated sessions, bypass MFA, and potentially gain internal access.

• Identified in active exploitation campaigns over 11.5 million attack attempts observed; CISA added CVE‑2025‑5777 to Known Exploited Vulnerabilities Catalog on July 10/14, 2025

[•] Attack Vector & Complexity

• Attack Vector: Remote, unauthenticated access via HTTP POST to /p/u/doAuthentication.do

• Complexity: Low. No credentials needed; trivial to script repeated requests.

• Authentication: Not required at all. Malformed login parameter triggers the vulnerability.

[•] Affected Versions

Citrix NetScaler ADC / NetScaler Gateway:

• 14.1 prior to 14.1‑43.56

• 13.1 prior to 13.1‑58.32

• 13.1‑FIPS / NDcPP prior to 13.1‑37.235

• 12.1‑FIPS prior to 12.1‑55.328

• EOL versions (12.1 and 13.0) are not patched and remain vulnerable; upgrade strongly recommended.

[•] Technical Details

• The /p/u/doAuthentication.do endpoint processes authentication POST requests.

• If an attacker provides the login parameter without an equals sign or value (e.g., login alone), backend C code fails to initialize the memory variable.

• The resulting XML response injects leftover stack memory in the <InitialValue> element.

• Each request may leak ~127 bytes of memory, often containing session tokens, credentials, or prior data.

Unauthenticated malformed request → memory leak via <InitialValue> in response → attacker repeats to gather data.

Example of a Malicious Request:

• Notice: no = or value after login parameter.

• Response: XML containing leaking stack memory in <InitialValue> tag. Repeatable to harvest multiple fragments.

[•] Mitigation & Response

1] Patch immediately!

• Upgrade to fixed versions:

  • 14.1 → 14.1‑43.56 or later

  • 13.1 → 13.1‑58.32 or later

  • FIPS/NDcPP, 12.1‑FIPS → apply corresponding fixed builds

• No effective mitigation exists other than patch — WAF signatures may help but are

  not reliable

2] Terminate active sessions post‑upgrade

• kill icaconnection -all

• kill pcoipConnection -all

• Ensures previously leaked tokens are invalidated.

3] Monitor & hunt

• Review logs for pointers to exploitation attempts.

• Deploy IDS rules to detect malformed /p/u/doAuthentication.do.

• Use anomaly analytics to catch suspicious behavior.

4] Network controls

• Restrict external access to NetScaler appliances (VPN endpoints or AAA servers).

• Segment appliance access behind VPN or firewall, limit exposure.

5] Follow up actions

• Engage forensic review if suspicious activity detected.

• Rotate credentials / tokens if session hijacking suspected.

• Use NetScaler Console insights or ADM file‑integrity monitoring for changes

[•] Honeypot Stats

On June 25th we deployed a fully interactive Citrix NetScaler honeypot designed to mimic a vulnerable Gateway environment and lure automated scanners, bots, and human attackers. The honeypot listens on port 443 and reproduces the authentic login portal, including /vpn/index.html, a realistic HTML/CSS/JS user interface, and key Citrix specific behaviors. We tied it to a freshly bought domain vipbank.org and setup SSL certs via LetsEncrypt.

Beyond the front end, the honeypot also exposes simulated backend vulnerabilities: requests to paths such as /menu/ss, /vpn/../vpns/cfg/smb.conf, and /rpc/../../../../../../../../etc/passwd receive plausible outputs, while any interaction with /p/u/doAuthentication.do is met with a crafted application/vnd.citrix.authenticateresponse-1+xml payload. This XML response follows the same schema as a real NetScaler authentication backend, including <PostBack>/p/u/doAuthentication.do</PostBack> and <CancelPostBack>/p/u/doLogoff.do</CancelPostBack> elements, so that scanners and exploit scripts believe they are interacting with a live, vulnerable appliance.

In parallel, every incoming connection is fingerprinted: the honeypot queries ipinfo.io to enrich the source IP with organization, location, and reverse DNS, which is displayed live on screen (only for hits to / and /vpn/index.html) and fully logged in netscaler_honeypot.log. These details are also stored more permanently via a companion toolset: ip_mapper.py parses the honeypot log, normalizes unique IP addresses, enriches them with metadata, and saves them into ips.db, an SQLite database designed for long term analysis and threat intelligence correlation. The result is not just a decoy login screen, but a full telemetry platform that lets us watch hostile traffic, track campaigns, and study exploit attempts as they happen.

The honeypot seems to have also attracted threat actors looking to exploit CVE-2019-19781.

At the core of the honeypot’s intelligence gathering is the ips.db SQLite database, which acts as a structured repository of every unique IP address that touches the honeypot. Each time the ip_mapper.py script is run against the honeypot logs, it extracts all valid IPv4 addresses and enriches them using the ipinfo.io API, adding details such as ASN/organization (org), country, city, reverse DNS hostname, and first seen timestamps. This data is stored in two main tables: ipinfo, which serves as the canonical record of each IP and its enrichment data, and ip_reputation, which logs any threat intelligence lookups performed on that IP against multiple OSINT feeds. This design allows us to correlate a single attacker IP over time even if it probes the honeypot weeks apart and track whether it belongs to a cloud provider, a known botnet, or an opportunistic researcher. Analysts can then query ips.db to build pivot tables of active regions, hosting providers, or recurring actors, enabling heatmaps of attacker origins and patterns of behavior. Over time, ips.db becomes a valuable dataset that highlights which organizations or autonomous systems are responsible for the majority of NetScaler attack attempts, providing context beyond just raw log files.

Populating ips.db via ip_mapper.py while checking IP reputation.

Querying top IPs with that have been labeled in 6+ reputation feeds.

A few more details on top offender IP: 128.1.40[.]207

Download RAW Logs: netscaler_honeypot.log
Download IP DB: ips.db