Seven Steps to Ransomware: CitrixBleed 2 Weaponized by Initial Access Brokers

A special thanks to the Huntress Security Operations Center (SOC) personnel, for without them we'd be describing the below incidents with far more painful details– and Lindsey Welch, who tirelessly proofreads our content on a moment's notice. Additionally, this blog was authored with AI assistance.

Introduction

Across the first half of 2026, the Huntress Tactical Response unit worked a string of intrusions that all rhymed: an edge Citrix NetScaler gateway, sudden anomalous access to the environment, a tidy privilege-escalation, a fake "Citrix" administrator account, off-the-shelf remote-access software, and when the operator got what they wanted—Dragonforce ransomware.

Huntress assesses with high confidence that an Initial Access Broker (IAB) is weaponizing CVE-2025-5777 (CitrixBleed 2) to gain access to Citrix environments, ultimately with the goal of deploying ransomware. In our observations, the ransomware deployed was Dragonforce, but public and private reporting finds indicators of other ransomware groups using this cluster as well, which forms the basis of our Initial Access Broker assessment.

Background

If you've investigated cybersecurity incidents for long enough, you know that most intrusions look a little different from one another. You learn to live with ambiguity: an RMM here, a phishing lure there, a webshell on a forgotten IIS box. Every so often, though, you work two cases back-to-back and feel a prickle of recognition—the same odd command line, the same throwaway account name, the same misconfiguration the attacker leaned on. Then you work a third. And a fourth.

That is what happened with the cluster we're calling, internally and unimaginatively, the Citrix NetScaler cluster.  

In the first half of 2026 (between January and June) we responded to a half-dozen incidents at unrelated organizations—different industries, different managed service providers, different parts of the country—that were so mechanically similar that by the latest case we could predict the next artifact before we pulled the log that contained it. We knew the account name the operator would create. We knew the service they'd abuse. We even knew the workstation name we'd find leaking through a printer mapping, because it was the same workstation name every single time.

Figure 1: Predictability and clustered behavior often presents the smoking gun for initial access.

Cybersecurity company Sophos has additionally tracked the cluster we've observed as STAC3725, echoing various analyses that we've presented in this article, and serves as an excellent vantage point to ground our analysis against. In our cases, we did not note the use of QEMU tooling for exploitation; we attribute this to rapid detection and dissolution of adversarial activities or the adversary's accelerated playbook after repeated disruption by security vendors. 

This blog is the consolidation of what we saw: the initial access vector and the forensics that proved it, the privilege-escalation primitive that ties the cases together, and the persistence and lateral-movement tradecraft.

Let's dig in.

Into the playbook

Before we go deep on any single technique, it helps to see the whole machine in motion, because the cluster's defining feature is its repetition. Strip away the org-specific noise and every case followed the same seven beats:

Figure 2: Citrix NetScaler to Dragonforce Ransomware killchain.

Not every victim experienced all seven beats. Some intrusions were caught and isolated at beat four or five; one ran all the way to ransomware before the partner pulled the plug. But the sequence never changed, and neither did most of the ingredients. When you see a kill chain reproduced this faithfully across unrelated environments, you are not looking at a coincidence. You are looking at an operator following a runbook. Almost certainly an initial access broker (IAB) or ransomware affiliate who has productized this exact path from "internet-facing Citrix box" to "domain-wide encryption."

A note on attribution: It is difficult in general to attribute threat actor behavior as either an IAB or ransomware affiliate due to overlapping tactics and limited visibility. Because we saw active encryption from DragonForce in one case in this cluster, we're confident in its relation to DragonForce, but we cannot say with certainty that the pattern we captured is clearly an IAB or a DragonForce affiliate itself. Furthermore, coordination with Sophos as well as threat bulletins published to security vendors has brought ambiguity into this cluster's association with a specific ransomware actor. We find it likely that the activity we've captured is a common and highly successful IAB.

Initial access: Bleeding a NetScaler

The single most important, and most misunderstood part of this cluster is how the operator got in. On first glance at the gateway logs, it looks like a brute-force attack: thousands upon thousands of failed logins, a torrent of garbage usernames, an obvious password-spraying campaign. That reading is wrong, and the difference matters enormously for response. 

The truth in the logs

On one of the appliances we examined, the NetScaler main system log file set (ns.log) contained 5937 AAA LOGIN_FAILED events sourced from the operator's IP addresses over a single ~5-hour window. Every one of them carried a bizarre, unprintable User value. Not a plausible user name, but binary noise littering the terminal with unprintable characters, escape sequences, etc.

Figure 3: Citrix appliance ns.log entries charting unprintable characters– these are leaked heap memory.

It is only upon closer examination that we were able to discern what this noise actually was. We stitched together the user name values and began to parse the data at large and what we found was not nonsense, but leaked heap memory from the Citrix appliance. A deluge of nonsense underscored data such as a leaked HTTP header, internal IP addresses, login flags, etc. 

CitrixBleed2 (CVE-2025-5777)

CVE-2025-5777, nicknamed "CitrixBleed 2" in the spirit of the original 2023 CitrixBleed (CVE-2023-4966) is a memory-overread in NetScaler ADC and Gateway when configured as a Gateway or AAA virtual server. The flaw is reachable pre-authentication. When the appliance receives a POST request to the login endpoint (/p/u/doAuthentication.do and equivalents) in which the login form variable is present but empty, it parses past the supplied data and serializes a chunk of adjacent process memory into the response, roughly 127 bytes per request. By spraying enough of those requests, an adversary can then sift through the heap fragments for valid session tokens of someone who is currently logged in. 

The two halves of the signature were present in our latest analysis: 

• The request side: a high-rate burst of malformed login POSTs from a single source IP, with the login parameter empty. On the appliances that captured it, this manifested as the failed-login flood.

• The response side: the leaked memory landing in the User field of the resulting AAA LOGIN_FAILED events, frequently preceded by the appliance's own diagnostic breadcrumbs: "Login request is not expected to be encrypted" and "X509 cert not found".

These two diagnostic log lines are not by themselves a reliable detection. The marker pair is necessary but nowhere near sufficient as forensic evidence. The discriminator that actually separates an attack from background noise is the binary data leaking through the user parameter, or even more simply, a session that exists with no corresponding session login.

Proving the session hijack

It's rare that forensics satisfyingly prove a hypothesis. In one incident, we were able to reconstruct from logs the entire attack chain: 

• A legitimate employee authenticated to the gateway normally, LDAP with MFA/OTP, from the user's known-good IP address at 13:07 UTC.

• Twenty-one minutes later, at 13:28 UTC, the same user's session was being actively driven from the adversary's IP address.

• There was no successful authentication from the attacker's IP anywhere in the logs.

A valid, fully authenticated session operated from an attacker's IP with zero successful authentication is only explicable one way: the session token was stolen and replayed. The memory bleed was demonstrably active during the victim's live session, the attacker rode that session minutes later, and MFA was simply irrelevant. It was already satisfied. 

It's worth noting that an alternative hypothesis was also pursued. Presently, there is a vulnerability in NetScaler session management whereby a time-of-check/time-of-use session mixup (CVE-2026-4368) can also produce a user accessing another user's sessions. It's a tempting fit, but it didn't hold for these cases on two independent grounds. The affected appliance build was outside that CVE's vulnerable range, and the race condition requires the attacker to hold an authenticated session to race against, which never existed in our logs. The evidence pointed squarely at memory disclosure.

Carving the leak

Because the leaked bytes are there in the logs, we're given a decent chunk of what data was enumerated. We extracted all User-field values from the logs (about 382 KB of raw heap) and carved them for coherent structure. 

We reassembled the leaked heap fragments (which themselves are not contiguous, but may reveal patterns) and uncovered the following data: 

• Reflection Template: A tiny HTTP response with Content-Length: 5 (the five characters of the empty login variable) and Content-Type: text/plain; charset=utf-8, immediately followed by the heap slice. 

• X.509 / ASN.1 certificate data: Sequence headers, object identifiers such as basicConstraints, keyUsage, subjectKeyIdentifier, etc., consistent with the Let's Encrypt server certificate.

• Live Traffic Metadata: Netscaler's proxy headers such as Citrix-ns-orig-srcip, Citrix-ns-orig-destip, etc., which exposed internal client IP's behind the data, along with Host headers and other HTTP metadata. 

And, in the spirit of honesty, we didn't recover a session cookie. It is the unfortunate nature of this vulnerability that visibility is heavily occluded and difficult to land reliably with the rate that ns.log rotates. However, we stand on the merits that the attack pattern and corresponding public reporting by other organizations proves with merits that CitrixBleed 2 presents the most likely attack vector. 

Printing wins

Our favorite initial access detail, however, is how we harvested adversary hostnames from the environment. When a user connects through Citrix, the published-desktop environment is kind enough to auto-create client printer mappings, which embed the client workstation name. 

Because the operator rarely changed their machine name, we were able to triangulate the adversary's activity in the Windows Application event log of the victim servers, case after case, via the Citrix "Print to PDF"  auto-creation event: 

WIN-4EOAP4JTJR9 (and a sibling, WIN-VI960VQI4I6) showed up in incident after incident. You can also correlate the malicious client to a specific session by pivoting between the Microsoft-Windows-TerminalServices-LocalSessionManager/Operational channel (which records the source IP and session ID) and the MetaFrameEvents provider in the Application log (which ties that session ID to the leaked printer/client name). It's a gift that keeps on giving: a default Citrix behavior that quietly fingerprints the operator's own machine. 

Privilege escalation made easy

If CitrixBleed 2 is how the operator gets in, the privilege-escalation primitive is what makes this cluster unmistakable. It is the same trick, executed the same way, in every endpoint case and it's clever enough to deserve a careful walkthrough. 

Why escalate

The subtle but interesting point predicating the privilege escalation activity: the session the operator hijacks often belongs to a normal user, an employee who logs into a published Citrix desktop to perform their regular job. These accounts are often unprivileged. The adversary lands inside the environment with the access of a regular user and must elevate to SYSTEM to install the services, create the accounts, etc., that we will detail later in this blog. Rather than hunt for an environment-specific misconfiguration each time, the adversary brings a portable, reliable local-privilege escalation (LPE) tool and uses it everywhere. The use of this tool allows us to reliably cluster this behavior.

Figure 4: Adversary-controlled user executing the LPE application, which relaunches AppMgmt.

Figure 5: LPE mechanism, now executing at NT AUTHORITY\SYSTEM, creating the backdoor user.

The dropper

The tool itself is a small unsigned executable, dropped to a working directory such as C:\temp, C:\logs, user downloads, etc, and renamed frequently per victim– eng.exe, legal.exe, as.exe, etc. It is frequently delivered inside a password-protected archive pulled from the file-sharing service temp[.]sh. The zipfile itself is often named similar to the executable. We were able to successfully crack the password of this zip archive, loko123, to gain access to the privilege escalation tool that the adversary was using. 

How the LPE works

The actual mechanism is a lovely piece of Windows internals abuse.

The Windows registry supports a special value named SymbolicLinkValue of type REG_LINK. When present under a key, it turns that key into a symbolic link: anything reading or writing through the key is transparently redirected to the link's target, much like a filesystem symlink. The exploit: 

1. Plants the symlink. It creates a REG_LINK SymbolicLinkValue under a device-class key– specifically the RdpBus device class GUID {28d78fad-5a12-11d1-ae5b-0000f803a8c2} and points the link's target into the Group Policy state hierarchy: …\Group Policy State\Machine\GPO-List\test

2. Fires the redirect as SYSTEM. By running gpupdate, the adversary forces a policy refresh which makes the GP engine re-process machine policy. That engine runs as SYSTEM. When it reads and writes through the planted REG_LINK, it follows the symlink to wherever the attacker aimed it, letting a SYSTEM-context write land in a protected key the unprivileged user could never touch directly.

3. Detonates by starting a service. With a hijacked configuration now planted in a protected service/GPO key, the operator starts the affected service via cmd.exe /c sc start AppMgmt >nul 2>nul which starts the Application Management (AppMgmt) service. This service causes the Service Control Manager (SCM) to launch the hijacked configuration in privileged context– relaunching the dropper as SYSTEM. This ultimately serves to create the backdoor user with elevated privileges.

4. Cleans Up After Itself. Before detonating, the exploit snapshots the original target key tree– walking every subkey and stashing the original values and paths. After it has executed, it restores the registry, leaving it in its original state. The cleanup serves to evade detection: by leaving the registry indistinguishable from its pre-exploit state, the tool removes the artifacts a responder would normally key on.

Figure 6: main showing the sync loop, NtDeleteKey teardown of the planted GPO-List\test\test keys, a final RdpBus trigger, and the "Restoring registry…" cleanup that returns the registry to its original state

Why AppMgmt?

The choice of AppMgmt as the detonation vehicle is deliberate from the attacker's perspective. AppMgmt is a built-in Windows service that runs in the background via appmgmts.dll service DLL. Its legitimate job is software deployment via Group Policy and Windows Installer (MSI). That means: 

• It's always present 

• It's plausibly related to what's happening 

• It's normally dormant 

The proof that the escalation worked is quite concise. It first executes in the context of the unprivileged user, then immediately after the execution of sc start AppMgmt, the next commands are ran from the same binary as NT AUTHORITY\SYSTEM, because the SCM relaunched it. The following commands are always the same: 

• net user <ctx-account> <hardcoded-password> /add /y

• net localgroup Administrators <ctx-account> /add

A note on attacker fallibility

Worth a small grin: in one case, our analysts noticed the operator's typos in the automation, a stray gpupdate /force fired through the dropper at an odd moment (a malformed command), and elsewhere in the cluster a delightful useeeer where user was intended. 

Figure 7: "net useeer" is entertainingly not a valid command, but the adversary seems excited.

Even productionized tradecraft is run by a human who occasionally fat-fingers the keyboard. It doesn't change the outcome, but it's a useful reminder that the operator is automating the attack, not auto-magically executing ones. 

Settling in

With a backdoor admin in hand, the operator establishes hands-on-keyboard persistence using legitimate remote-management tooling, the now-standard "live off the land of trusted software" approach that frustrates naive allow-listing. 

What did we find? Well… 

ScreenConnect, mostly

The most common choice was a rogue ScreenConnect client, installed via a small MSI (us.msi, SC.msi, 1111.msi) and configured to call home to attacker-controlled relay infrastructure. We directly recovered configurations from the client's launch parameters. The relay host and port, and the instance ID are baked into the client's command line and install path. Across several cases, we found the following relays and instance IDs: 

• Relay relay.dltsolutions[.]top, instance ID 9963f404a99f0fc4

• Relay relay.eurofin[.]digital:8041, instance ID aee74a66ea5bb239

Zoho Assist backup

In several cases, the operator also (or instead) installed Zoho Assist via za.msi, present across several cases in the cluster. We've chosen to withhold harvested indicators from Zoho Assist, as several likely-stolen credentials were recovered that expose compromised Outlook users of unrelated environments. 

Netbird/Atera

And in a singular case, near the beginning of the adversary's tradecraft evolution, we noted a Netbird/Atrea combination was deployed, echoing Sophos' Netbird observations. In this environment, Netbird was configured to communicate with hxxps{://]opa[.]tlsd[.]shop, whereby once this was established, Atera was downloaded through the standard Atera support link.

Actions on objectives

What happened after the footholds were established varied with how long the operator was allowed to dwell, which in turn depended heavily on the adherence to Huntress' remediation guidance. In some instances, remediations were not completed successfully and the Citrix appliance was not patched, leading to subsequent re-access by the adversary. 

Hands-on keyboard

In cases that progressed, the operator used the backdoor admin to: 

• Log back in interactively via RDP using the freshly minted administrator accounts.

• Run PsExec against local hosts with the -s flag to obtain a SYSTEM shell. 

• Conduct host and session reconnaissance – qwinsta, whoami, wmic, etc. 

• Deploy Impacket tooling against domain controllers, dropping RemCom-based binaries. In one case, Microsoft Defender successfully quarantined Impacket's remote execution payload and the registry dumping activity, buying Defenders valuable time.

• Dump credentials with Mimikatz, run from anomalous directories (e.g., C:\Binaries)

The objective: Dragonforce ransomware

In the most progressed case we worked, the operator reached the goal line. After establishing a backdoor admin on the victim's server, they pulled and executed a DragonForce ransomware binary (1.exe), which resulted in encryption of the environment. Rapid triage by Huntress analysts successfully mitigated the encryption to the singular host, but the intent of the cluster was never ambiguous following encryption.

The association with DragonForce, the consistent tradecraft, and the reuse of infrastructure and account names across unrelated victims are why we assess this cluster as a single IAB/affiliate operation rather than a loose pattern of opportunistic, independent intrusions. 

Taking action

This should serve as a call to action for users of Citrix NetScaler appliances. It's time to patch, right now. In one environment, we observed an adversary gain access and complete their exploitation in less than an hour and deploy ransomware, stopped only by Huntress mass isolation measures, dissuading further access. Here are some immediate steps that businesses can take:

• Patch Citrix NetScaler appliances to the latest software version, and regularly review the appliance for updates. 

• Forward NetScaler logs to SIEM solutions/log retention. NetScaler logs rotate quickly and device logs may only ephemerally contain evidence of compromise. It's critical to retain this data for review. 

  • If interested in log reviewing yourself, NetScaler has put out a fantastic article in hunting for signs of CitrixBleed2 compromise. 

• Terminate outstanding sessions for appliances vulnerable to CVE-2025-5777. Session tokens harvested may be durable in nature and provide adversarial access even after patching. 

• Audit vulnerable Citrix environments for CtxAppVCOMService, ctxsvc, and test users that do not belong. (Noting test may be a legitimate/ambiguous user in some environments.)

• Audit vulnerable Citrix environments for unanticipated ScreenConnect and/or Zoho Assist instances. 

Indicators of Compromise (IoCs)