Fully Patched Ivanti VPN Hacked to Root With Zero Malware: How UTA0576 Hunted AD Credentials and BitLocker Keys

The appliance was on 22.8R2.4, Build 19097. That was the latest release on its branch. On October 3, someone sent it an unauthenticated request to /dana-na/auth/url_default/welcome.cgi with a crafted X-DSCGI-PATH header, and within the same chain they were running as root.

Volexity picked up the trail two days later, on October 5, while investigating suspicious activity inside a customer network and tracing it back to the VPN. Ivanti published fixes and an advisory for CVE-2026-104935 (CVSS 8.6, CWE-290, authentication bypass by spoofing) on October 13. CISA added it to the Known Exploited Vulnerabilities catalog the same day and gave federal civilian agencies until today, October 16, to remediate.

If you run Connect Secure, you probably already have the patch ticket. This post is about something else: what the attacker, tracked by Volexity as UTA0576, actually did after landing, and why almost none of it would have shown up in the tools most teams point at a VPN appliance.

Three bugs, two fixed, one still open

The chain has three links. Per Volexity's write-up and the coverage in The Register and SOCRadar:

1. Authentication bypass. Request routing on welcome.cgi is manipulated through the X-DSCGI-PATH header so a protected CGI handler answers an unauthenticated caller.
2. Code execution. The upload handler wu.cgi is abused to stage and run code as the cgi-server user. These first two are what CVE-2026-104935 covers.
3. Privilege escalation. A separate bug in the dsinvoked service and the DSCache configuration store lifts cgi-server to root. As of October 13 this one has no CVE and no patch. Ivanti says a fix is coming "in the coming weeks."

Fixed builds are 22.8R2.5 and the 25.1.3.x line, depending on which branch you're on. SOCRadar flagged a conflict between Ivanti's advisory and public CVE data on whether 25.1.1.2 is enough, so check the advisory for your exact build rather than trusting a summary table. Ivanti is also nudging customers to 25.x because the 22.7 and 22.8 branches reach end of life on January 31, 2027.

One detail made me wince. Ivanti told reporters its product security team found "a portion of this vulnerability" during internal checks in June, shipped protection for it in the July 25.1.3.0 release, and decided it "did not meet the threshold for an out-of-band release." It was still backporting the fix to older branches when UTA0576 started exploiting it. That's the gap that matters: if you were on the 22.8 line and fully patched, you were exposed to a bug the vendor already knew about.

And with the root step unpatched, a patched appliance still has a known path from cgi-server to root if anyone finds another way onto that user. Treat the appliance as exposed until the third fix ships.

No malware, no web shell, nothing to scan

Here's the part that should change how you think about edge appliances.

UTA0576 didn't drop a backdoor. There was no web shell. The initial stage was a Perl payload, followed by an encoded Python stage that lived in memory. Everything else used binaries already on the box. When they were done, they deleted recent entries from the debug and audit logs, removed their own payloads, cleaned up temp files in /home/runtime/tmp/, /tmp/ and /data/.icscap/, and reverted the in-memory library and configuration changes they'd made.

The result: Ivanti's Integrity Checker Tool did not detect the compromise. SOCRadar's summary of Volexity's findings is blunt about it. The chain modifies code only in memory and restores what it touched, so the checker "does not detect any modifications."

Every Ivanti incident since 2024 has ended with the same advice: run the Integrity Checker, and if it's clean, breathe. That advice is now wrong on its own. A clean result tells you nothing about whether UTA0576, or the next crew who reads Volexity's report, was on your box last week.

I've spent a lot of time writing detections for edge devices, and this is the pattern I keep coming back to. The appliance is a black box you can't install an agent on. Its own logs are writable by root. Its own integrity tool checks files on disk. An attacker who stays in memory and cleans up after themselves has beaten all three before you've opened a ticket. We saw the same shape with NetScaler CVE-2026-88771 and the F5 BIG-IP APM token-signing flaw: the appliance is where the attacker starts, but the evidence you can trust lives somewhere else.

So let's go somewhere else.

What they went after, step by step

The useful part of Volexity's report is the post-exploitation list. Read it as an attacker's shopping list, and it's almost entirely identity material. Here's each item and what it would have looked like from outside the appliance.

1. Credentials stored on the appliance

First stop was the appliance's own stored secrets, including the domain service account Connect Secure uses to bind to LDAP. Every VPN that authenticates against Active Directory holds a credential like this, and it's usually over-privileged because nobody wanted to debug a failed bind at 2 a.m.

Where you'd see it: Not on the appliance. You'd see it later, when that service account authenticates from somewhere it never has before: a workstation, a jump host, a different subnet. If your SIEM has a baseline for the VPN's bind account, an off-baseline logon is the earliest signal you'll get.

2. LDAP traffic capture

UTA0576 ran tcpdump renamed as dsstatmond, a name chosen to blend in with Ivanti's own daemons. They captured plaintext protocols, filtered for LDAP on TCP 389, and tried to exfiltrate the first 8 KB. A companion script parsed captures for plaintext LDAP binds, HTTP Basic credentials, and NTLM challenge-response material.

That 8 KB detail is telling. They weren't after bulk data. They wanted the first few bind operations, which on a VPN appliance means usernames and passwords of real users logging in, in cleartext if your LDAP isn't signed and sealed.

Where you'd see it: Honestly, mostly nowhere, unless you'd already moved the appliance to LDAPS on 636 and enforced LDAP signing. If you haven't, that's a project worth starting this week regardless of Ivanti.

3. Active Directory reconnaissance for the good stuff

With a working domain credential, custom LDAP tooling queried AD and exported results as JSON. The attributes they asked for are the giveaway:

• ms-Mcs-AdmPwd and Windows LAPS password attributes (local administrator passwords)
• BitLocker recovery information (msFVE-RecoveryInformation objects)
• userPassword and unixUserPassword, which some legacy integrations still populate in cleartext or weak hashes
• Logon script paths, which tell you which file shares every user's machine trusts at login

Nobody queries all of those at once for a legitimate reason. A help desk tool might read one BitLocker key for one machine. A sweep that reads LAPS, BitLocker, unixUserPassword and script paths across the directory is someone building a lateral-movement plan.

Where you'd see it: Directory Service Access auditing (event 4662) with SACLs on the confidential attributes, if you've configured them. Most shops haven't, because the event volume is painful. This is exactly where a decoy beats a rule, and I'll come back to it.

4. Kerberoasting

One script included Kerberoasting functionality. That means requesting service tickets for accounts with SPNs, then cracking them offline. It's old, it's quiet, and it still works because service account passwords are still set once and forgotten.

Where you'd see it: Event 4769 with RC4 encryption (0x17) for accounts that normally only see AES. Noisy in a big domain, but useful if you narrow it.

5. Password spraying

They pulled usernames out of the appliance's own authentication logs, then ran a spraying script that wrote out a list of successful hits. Think about how efficient that is: the VPN log is a curated list of valid, active, remote-access accounts. No guessing at naming conventions.

This is the same move we covered in the Chilean spray that only hit forgotten service accounts. Attackers love an account list they didn't have to build.

Where you'd see it: Event 4625 bursts, or Entra sign-in failures if the spray went cloud-side. Spray tooling now paces itself well below most lockout and alert thresholds, though.

6. Cleanup

Then the log deletion and memory restoration. Volexity assesses with high confidence that everything above was preparation for lateral movement and wider compromise. The operation was disrupted before that happened, so we don't know the end goal. Volexity leans, with low confidence, toward a criminal motive. Ransomware crews would pay very well for LAPS passwords and BitLocker keys.

The LLM angle is real, and it's a detection gift

Volexity assesses with medium confidence that UTA0576 used large language models for exploit development and post-exploitation. The Register quotes their reasoning: repeated use of the exploit channel to run commands, and "highly specific scripts using hardcoded credentials."

Most coverage treats that as the scary part. I'd argue the opposite. An operator who generates a fresh, tightly scoped script for each step, with hardcoded credentials baked in, is an operator who uses whatever credential they found, immediately, without much judgment about whether it's real. A human with ten years in the field might pause at a service account that looks too convenient. A script written in thirty seconds to "test these credentials against the domain" won't.

That asymmetry is the whole case for deception at this layer.

Where a tripwire would have fired

Go back through the list and ask a different question: not "what logs would show this," but "what could I plant that this attacker would touch, and that no legitimate process ever would?"

A decoy bind credential on the appliance. If Connect Secure has room for an additional auth server config, a second LDAP server entry with a believable service account that exists in AD but is never used for anything is a high-value bait. The first time it authenticates anywhere, you know the appliance's secrets have left the box. No baseline, no tuning, no false positives, because no legitimate system ever uses it.

Fake LAPS and BitLocker entries. Create a handful of computer objects that look like servers, populate LAPS password attributes and BitLocker recovery objects with credentials that go nowhere, and alert on any authentication using those local admin passwords. A sweep like UTA0576's reads them along with everything else. The moment someone tries Administrator with one of those passwords against anything, you have a confirmed intruder with a known source.

A Kerberoastable honey account. One user with an SPN, a strong random password nobody will crack, and an alert on any 4769 request for it. No service ever asks for that ticket. Kerberoasting tools enumerate every SPN they can find, so they always grab it.

Decoy services on the paths the logon scripts point to. UTA0576 pulled logon script paths for a reason: those shares are where you go to push code to every machine. A decoy file server in that address range, of the kind MineField stands up, gets touched the first time someone goes looking.

A seeded username in the VPN auth log. This one's my favourite and it's cheap. Have a scheduled task attempt a VPN login with a decoy account now and then, so the username appears in the appliance's logs. When an attacker scrapes those logs for a spray list, the decoy goes in with the real ones. Any successful or failed auth for that account from anywhere other than your task is someone working from a stolen list.

None of these depend on seeing inside the appliance. That's the point. When the vendor's own integrity tool can't see the compromise, the detection has to live in the places the attacker has to go next, and each of those can be seeded. If you want the broader map of where these fit across identity and cloud, our deception solutions overview walks through it.

What to do this week

The short list, in priority order:

• Patch to 22.8R2.5 or the 25.1.3.x line, confirming the exact fixed build for your branch in Ivanti's advisory. Then plan for the third fix, which isn't out yet.
• Don't treat a clean Integrity Checker run as an all-clear. Volexity's guidance is memory and network forensics. At minimum, look for outbound connections to 108.165.147[.]64 (which ran an OpenVPN server from September 30 to October 7) and for any process named dsstatmond that isn't Ivanti's.
• Rotate the appliance's LDAP bind credential and any other secret stored in its config, whether or not you've found evidence. Assume they're read.
• Rotate LAPS passwords for every machine and audit who can read BitLocker recovery objects. If the VPN bind account can, fix that first.
• Enforce LDAP signing and channel binding, and move the appliance to LDAPS. Plaintext LDAP on 389 handed this actor real user passwords.
• Hunt for 4769 RC4 requests and 4625 bursts from the appliance's IP range since October 1.

CISA lists 36 Ivanti defects in KEV since late 2021, and Connect Secure has now had zero-days disclosed in January 2024, January 2025 and October 2026. I don't say that to pile on Ivanti; Citrix and F5 have had their own rough months. I say it because the edge appliance is going to get popped again, by someone, on a build you thought was current. The useful question isn't whether you can prevent that. It's whether you'll know within minutes when the attacker starts using what they took.

If you'd like to see how decoy LAPS entries, honey SPNs and fake bind accounts would sit in your own directory, book a Mine2 demo and we'll map them against the exact steps UTA0576 took.