How to Contain Active Directory Exposure After a VPN Appliance Is Compromised

Start from what the attacker could have read

When a VPN appliance is compromised, the incident does not end at the appliance. Gateways store the credentials they use to bind to Active Directory, and they see every user's password in transit as people log in. In the Ivanti Connect Secure zero-day CVE-2026-104935, Volexity reported that attackers extracted the appliance's LDAP credential, used it to search the directory for LAPS passwords and BitLocker recovery information, ran password spraying and Kerberoasting, and captured plaintext protocol traffic from the box.

Containment means working out what that exposure covers and then making all of it worthless. The order matters, because rotating in the wrong sequence can tip off an active intruder or lock out your own staff.

Step 1: Preserve, then isolate

Before you change anything, keep what you will need later: appliance logs, configuration exports, and a system image if the vendor supports one. Our guide How to Preserve Forensic Evidence on a Network Appliance Before You Patch It covers this in detail. Then cut the appliance off from the internal network, or rebuild it. Rotating credentials while the attacker still has a foothold that can read the new ones accomplishes nothing.

Step 2: Scope the service account

Pull the effective permissions of the appliance's bind account from the directory side. You need to know which organizational units it could read, whether it could read LAPS passwords, whether it could read BitLocker recovery objects, and whether any accounts in scope carry password-bearing attributes such as userPassword. What an Appliance's LDAP Service Account Can Read in Active Directory explains where those permissions usually hide.

If directory auditing was enabled, look for searches from that account during the exposure window. Their absence is weak evidence. Volexity observed log tampering on the appliance, and directory read auditing is often off.

Step 3: Rotate the appliance's own credentials

Reset the bind account's password and set a new one on the rebuilt or patched appliance. While you are there, cut the account down to what it needs. Also rotate any other secrets stored on the box: RADIUS shared secrets, certificates and private keys, API tokens for management platforms, and local admin accounts on the appliance.

Step 4: Rotate the secrets it could read

This is the step most teams skip, and it is where the real damage sits.

• LAPS passwords. Force a rotation for every computer in the OUs the account could read. LAPS supports an immediate expiry so each machine sets a new password at its next policy refresh. Confirm afterwards that the new passwords were actually written back.
• BitLocker recovery keys. A leaked recovery key unlocks that disk forever unless the protector is replaced. Generate new recovery passwords for affected machines and back them up again. Prioritize laptops, which are the devices most likely to end up in someone else's hands.
• Password-bearing attributes. Clear legacy userPassword or unixUserPassword values that should not exist, and reset the passwords of the accounts that had them.

Step 5: Reset users the appliance saw

A gateway handles the passwords of everyone who logs in through it, and this attacker ran a packet sniffer on the box. Treat every account that authenticated during the exposure window as exposed. That includes users, admins who logged in to manage the appliance, and service accounts used for health checks. Reset them, and revoke active sessions and refresh tokens where your identity provider allows.

Accounts that may have been hit by password spraying need the same treatment. Look for failed-then-successful patterns from the appliance's addresses.

Step 6: Deal with Kerberoasting exposure

Kerberoasting targets accounts with service principal names: the attacker requests a service ticket and cracks it offline. You cannot see the cracking, so assume any service account with a weak or old password is compromised. Rotate service accounts with service principal names, starting with privileged ones. Where possible, move them to managed service accounts with automatically rotated passwords.

Step 7: Watch for reuse

Rotation shuts off the stolen material. Monitoring tells you whether it was used before you got there. For the following weeks, watch for:

• Local administrator logons on workstations and servers, especially from unusual sources.
• Logons by the old bind account or reset users from outside expected networks.
• Kerberos service-ticket requests for many SPNs from a single source.
• New persistence on endpoints whose LAPS passwords were exposed.

Order of operations recap

1. Preserve evidence.
2. Isolate or rebuild the appliance.
3. Scope the bind account's read access.
4. Rotate appliance-held secrets.
5. Rotate LAPS passwords and BitLocker recovery keys in scope.
6. Reset users and service accounts the appliance saw or could target.
7. Monitor for use of anything you missed.

If the vendor says a patched appliance is clean because an integrity scan passed, read Why a Clean Integrity Check Cannot Clear a Compromised Appliance before you put it back into service.