Ivanti Connect Secure: UTA0576 steals AD credentials

In the first week of October 2026, Volexity spotted a previously unknown group, which it tracks as UTA0576, compromising an Ivanti Connect Secure (ICS) appliance running the latest version available at the time, 22.8R2.4. The group chained three zero-day vulnerabilities (an authentication bypass, remote code execution and privilege escalation) to obtain root privileges without credentials.

On 13 October Ivanti published its advisory and fixes for the first two flaws, grouped under CVE-2026-104935 (CVSS v3.1 8.6). The privilege escalation is not fixed yet: according to Help Net Security and Security Affairs, the fix will come in a later release. Ivanti says exploitation is limited to a small number of customers. CISA added the CVE to its KEV catalog the same day and ordered US federal agencies to update and perform forensic triage by 16 October. Advisories were also issued by BSI/CERT-Bund (Germany), CCB (Belgium), INCIBE-CERT (Spain) and KISA/KrCERT (South Korea).

This article focuses on what the group did after gaining access, because that is where defenders will find the most useful traces.

Timeline

• 1 October: according to Defused Cyber, cited by Help Net Security, the earliest confirmed activity of this campaign.
• 3 October: according to Security Affairs, the attacker was already inside the appliance of Volexity’s customer.
• 5 October: Volexity starts investigating suspicious activity and traces it back to the VPN.
• 13 October: Ivanti advisory and fixes, addition to the KEV catalog (date reported by CSO Online).

Ivanti had already found “a portion” of the vulnerability through its own security program and fixed it in July in 25.1.3.0; it was backporting the fix to the other supported branches when the attacks began.

Why the Integrity Checker is not enough

According to Volexity, the chain modifies code in memory only and then restores the configuration data: Ivanti’s Integrity Checker Tool (ICT), which checks files on disk, sees nothing. For every command the group re-ran the whole chain and received the output in normal HTTPS responses, with no web shell or persistent backdoor. Temporary files were removed immediately, and selected entries in Ivanti debug logs and Linux audit logs were deleted. Determining whether an appliance was compromised therefore requires a forensic investigation, as Volexity and CISA point out.

What it looked for in Active Directory

The most relevant detail for organisations is what the attackers went after. According to Volexity’s report, as covered by Security Affairs and Help Net Security, right after gaining access UTA0576:

• used a Python LDAP tool that authenticated to a domain controller with the VPN appliance’s own service account;
• searched Active Directory for LAPS local administrator passwords, BitLocker recovery keys and attributes containing plaintext passwords;
• captured LDAP traffic passing through the appliance to collect cleartext credentials, using a renamed, hidden tool and eight rotating capture files;
• ran Kerberoasting attacks with its own Kerberos implementation and password spraying campaigns against domain accounts;
• exfiltrated configuration data and results, compressed and encoded, through the same channel.

Volexity assesses with high confidence that the group was preparing lateral movement and a broader compromise, which was cut short when it was discovered. Confidence on motivation is low: more likely criminal than espionage. Only Security Affairs also reports that, according to Volexity (medium confidence), the group uses large language models to develop exploits and post-exploitation tooling.

In MITRE ATT&CK terms: T1190 for initial access, T1068 for privilege escalation, T1070 for indicator removal, T1040 for network sniffing, T1558.003 (Kerberoasting), T1110.003 (password spraying) and T1041 for exfiltration.

Affected and fixed versions

According to the INCIBE-CERT and KISA advisories:

• 22.8R2.4 and earlier in the 22.8 branch: update to 22.8R2.5, then Ivanti recommends moving to the 25.1 branch;
• 25.1.1.1 and earlier: update to 25.1.1.2;
• 25.1.2.2 and earlier: update to 25.1.3.0, 25.1.3.1 or later.

22.7R2.14 and earlier are not affected by CVE-2026-104935. According to CSO Online, Ivanti says reliable indicators of compromise are not yet available and points to those published by Volexity.

In the same October bulletin, summarised by INCIBE-CERT, Ivanti also fixes two critical flaws that are not being exploited: CVE-2026-106042 in Xtraction (update to 2026.4) and CVE-2026-109412 in Neurons Patch for Intune, already fixed in the cloud on 16 September; for the latter Ivanti recommends rotating the client secret of the application registered in Microsoft Entra ID.

Impact for European and Italian organisations

The VPN is the entry point for employees, suppliers and maintenance contractors, and its service account often has read access to much of Active Directory. The key point is that stolen credentials remain valid after patching: LAPS passwords, BitLocker keys, accounts with SPNs and accounts guessed through spraying must be considered exposed if the appliance was compromised.

For entities in scope of NIS2, patching is part of vulnerability handling with documented timelines; a confirmed compromise must be assessed for notification to the national CSIRT (in Italy, CSIRT Italia at ACN, with an early warning within 24 hours for significant incidents). In healthcare, where the VPN often provides remote access for doctors and medical device suppliers, BitLocker keys and local administrator passwords open the way to clinical workstations.

What to do now

1. Preserve evidence before updating a suspicious appliance: logs, configuration backups and system images (INCIBE-CERT guidance).
2. Update every appliance and every cluster node to the fixed version for your branch; run the ICT, but do not treat a clean result as proof of integrity.
3. Check Active Directory from the domain controllers’ side: LDAP queries by the VPN service account for LAPS attributes, BitLocker recovery objects and password attributes; spikes in Kerberos ticket requests from the VPN’s internal address; bursts of failed logons across many accounts.
4. If compromised, follow Ivanti’s recovery steps and rotate: the VPN service account password, LAPS passwords, BitLocker recovery keys, and the passwords of accounts with SPNs and of accounts targeted by spraying.
5. Reduce exposure: restrict the VPN service account to the minimum permissions it needs and use encrypted LDAP connections, so traffic passing through the appliance does not carry cleartext credentials.
6. Follow Ivanti’s advisory for the privilege escalation fix and install it as soon as it is released.

How ARXDOME helps

ARX Expose shows which services your organisation exposes on the internet and which have known vulnerabilities, so you know right away whether a remote access gateway can be reached from outside. ARX Sentry sends firewall and network device logs to a central collector, away from the appliance: deleting local logs does not erase what has already been sent. The SOC identity pages highlight bursts of attempts, privileged logons and account changes, which help spot password spraying and the use of stolen credentials.

Last updated: 14 October 2026