Ivanti’s October zero-day was a directory incident that came in through the VPN

The week

On Tuesday, October 13, 2026, Ivanti released a fix for an authentication bypass in Connect Secure, its remote-access VPN appliance. The flaw was already being exploited. The same day, CISA added it to the Known Exploited Vulnerabilities catalog as CVE-2026-104935 and gave federal civilian agencies until Friday, October 16, to deal with it. The catalog entry carried a requirement introduced in June: forensic triage. Agencies had three days to patch and to establish whether they had already been compromised.

The attacks had started well before the announcement. Defused, a threat intelligence firm that runs decoy systems, said its sensors caught exploitation from October 1. Volexity, the security firm that worked out the attack chain, traced the first activity by the actor it calls UTA0576 to October 3. Volexity began investigating suspicious activity at one of its monitoring customers on October 5. The entry point was a Connect Secure appliance running version 22.8R2.4, fully patched at the time.

Volexity published its analysis on October 13. It described a chain of three flaws. An authentication bypass let requests reach protected parts of the device. A file write flaw, exploited through a race condition, turned that access into command execution. A privilege escalation flaw then gave the attacker root. The vendor’s October 13 fix covered the first two. The third had no patch when the week ended.

What the attacker did next defined the incident. Volexity found no web shell and no malware. The actor re-exploited the device for each command, patched code in memory and then restored it, and deleted entries from the appliance’s debug and audit logs. It extracted credentials stored on the appliance, including the domain account the device used to query Active Directory over LDAP. With that account, it searched the directory for local administrator passwords managed by Microsoft’s LAPS, BitLocker recovery information, password attributes and logon script paths, and exported the results.

It also captured LDAP and other unencrypted traffic on the appliance, parsing it for credentials and NTLM password hashes, and ran password spraying and Kerberoasting tools. Volexity assessed with high confidence that this was preparation for moving deeper into the network. It assessed with low confidence that the motive was criminal rather than espionage, and with medium confidence that the actor used large language models to build its exploit and tooling. The operation was detected and disrupted before its final aim became clear.

CISA’s alert on October 13 urged organizations to update immediately. It warned that the vendor’s own integrity checking tool might miss the intrusion, because the attacker’s commands ran in memory, and said confirming compromise would take network and memory forensics. For organizations that suspected compromise, it set out a rebuild of the appliance. Passwords were then to be reset for all accounts, including domain, administrator and local accounts, and stored certificates, API keys and license server credentials replaced. The alert did not mention LAPS passwords, BitLocker recovery keys or the other directory data the attacker had searched for.

The flaw was easy to trigger. Researchers at watchTowr said a single crafted request was enough to bypass authentication, and expected attacks to spread quickly from targeted to indiscriminate. By October 14, Previdian, which runs honeypot sensors, had logged 105 exploitation attempts from 50 IP addresses. The entry was the fifteenth Connect Secure or Pulse Connect Secure flaw in CISA’s catalog.

The deadline ran under Binding Operational Directive 26-04, issued on June 10. It replaced the 2021 directive that created the catalog with a scheme that weighs internet exposure, known exploitation, automation and technical impact. It also added explicit expectations for checking whether a system was compromised before it was patched. When CISA issued it, the agency said that applying a patch generally does not remove an attacker who is already inside, and that AI may shorten the time between a patch and its exploitation. Four months later, the Connect Secure chain tested both statements at once.

The October Ivanti flaw arrived framed as an edge-device emergency, and the federal deadline framed it the same way. The catalog entry named a product, Connect Secure, and gave agencies three days to patch it and decide whether it had been compromised. The attacker’s behavior pointed somewhere else. UTA0576 installed no web shell or backdoor on the gateway. What it went after was what the gateway could reach: the credentials stored on it, the directory its service account could query, and the traffic flowing through it.

That makes the reach of an incident like this a property of the identity system, fixed by permissions granted long before any advisory. A gateway whose directory account can read only group memberships exposes little beyond itself. A gateway whose account can read every workstation’s local administrator password and every laptop’s BitLocker recovery key exposes the fleet. Patching on time changes neither.

The exposure divides into three kinds of secret: secrets stored on the appliance, secrets its account can read elsewhere, and secrets that pass through it. Anything sensitive an edge device touches belongs to exactly one of them. After a short account of how a gateway is wired to the directory, the sections below take each kind in turn. Four further sections follow. They cover what a three-day clock can achieve and how the work divides among federal, state and local agencies. They then weigh the strongest case against acting on all of this, and set out the permissions worth setting in advance. Agencies should confirm their obligations under BOD 26-04, and any notification duties, with CISA and their own counsel.

How a remote-access gateway is wired to the directory

A remote-access gateway, often called an SSL VPN appliance, is the front door for staff working away from the office. A caseworker on a laptop at home connects to it, proves who she is, and is let through to the internal systems her role allows. Connect Secure, formerly Pulse Connect Secure, has filled that role in many agencies for years. CISA issued emergency directives about it in 2021 and again in 2024.

The gateway rarely keeps its own list of users. It asks the agency’s directory, usually Microsoft Active Directory, using a protocol called LDAP. To ask, it has to sign in to the directory with an account of its own. That account is variously called a bind account or a service account. Its password is stored on the appliance, because the appliance has to use it unattended, thousands of times a day.

Each time a user signs in, the gateway does two things with that account. It checks the user’s password, directly or by passing it to the directory to verify. Then it looks up the user’s group memberships, because its access rules are written in terms of groups: staff in one group reach the case management system, staff in another reach the finance network. A well-designed account needs very little to do this. It needs to find user objects, read a handful of attributes and read group membership.

Active Directory, by design, lets any signed-in account read a great deal: users, groups, computers and the names of the services that run under particular accounts. A small set of attributes is protected more tightly, and two of them matter here.

The first is the local administrator password managed by LAPS, Microsoft’s Local Administrator Password Solution. LAPS gives every Windows computer a different, regularly changed password for its built-in administrator account and stores it in the directory, on that computer’s record. That replaced the old habit of one shared administrator password across a whole fleet. It also concentrated a lot of power in one place. Whoever can read the attribute can sign in as administrator on that machine.

The second is BitLocker recovery information. BitLocker encrypts a laptop’s disk. If the laptop cannot unlock itself normally, a 48-digit recovery password opens it. Many agencies back those passwords up to the directory so the help desk can read one out to a stranded user. Whoever can read them can unlock the drive of any covered laptop that comes into their hands, including one that was lost, stolen or sent for disposal without being wiped.

Administrators decide who can read these attributes. The intended readers are few: the help desk for BitLocker, a desktop support group for LAPS. Over the years, service accounts drift into those circles. An installer guide suggests an administrative account to get the product working, and nobody narrows it afterwards. An engineer adds the account to a broad group while troubleshooting and forgets to remove it. A delegation granted at the top of the domain to all IT staff turns out to include it. One account gets reused across several appliances and applications, and accumulates the rights of all of them.

The account is also an orphan in most organizations. The network team installed the gateway and created the account years ago, often with a contractor. The identity team runs the directory but does not regard the gateway’s account as its own. Nobody reviews it, because nobody owns it. The October chain showed what that gap costs.

Secrets stored on the appliance

The first kind of secret is the one an attacker with root can take without asking anyone. A gateway like Connect Secure holds a predictable set.

• The directory account’s password.
• Credentials for any other authentication server it uses.
• The certificates and private keys that prove the gateway’s identity to users’ devices.
• API keys used by management or monitoring tools.
• License server credentials.
• Its own local administrator accounts.

Volexity found that UTA0576 extracted stored credentials, including the domain account used for LDAP. CISA’s recovery steps read like an inventory of the same list.

This category is the most bounded of the three. The agency can list every secret from the appliance’s configuration in an afternoon. Every one of them is the agency’s to change. And changing them needs nobody outside the agency, except perhaps a certificate authority.

It is also the category where a well-meant recovery can undo itself. CISA’s steps for a suspected compromise run in order: back up the configuration, reset the device to factory settings, upgrade, restore the configuration, then reset passwords and reissue certificates. The restore puts the old secrets back. A team that stops after the restore, because the device is clean, patched and working, has rebuilt the appliance around the very credentials the attacker took. Resetting every secret is the step that makes the rebuild worth doing. It is also the step most likely to be deferred, because it touches other systems.

Those other systems explain the deferral. Changing the directory account’s password breaks sign-ins until the new password is entered on the gateway and on anything else that shares the account. Reissuing the gateway’s certificate may need a change window and, where clients pin certificates, an update to every managed laptop. API keys are embedded in monitoring and configuration tools owned by other teams. Each change is small. Together they look like an outage risk, on a day when the team has already taken one outage to rebuild.

Sequencing matters as much as the list. Secrets should change after evidence has been collected and after the rebuilt device is running, so that an attacker still present on the old device cannot capture the new values. The directory account should change first, because it is the bridge to the second category. Certificates and API keys follow. Local administrator accounts on the appliance are replaced as part of the rebuild.

A rotation that does not break sign-ins is possible with a little preparation. The identity team creates a new account with the narrowed rights described later. The network team enters it on the gateway as the directory credential, and a test user confirms sign-in and group lookup. Only then is the old account disabled, not deleted, so it can be re-enabled if something else turns out to depend on it. Any later sign-in attempt by the disabled account is informative. It reveals either a forgotten dependency or someone still using the stolen credential.

The evidence is cheap, which is one reason to insist on it. Active Directory records when each account’s password was last set, so the rotation of a bind account can be shown from the directory itself, without relying on anyone’s ticket notes. Certificate issue dates show in the certificate. A one-page record per appliance, listing each secret, the date it was changed and the person who changed it, answers the question an inspector general or auditor will ask months later.

Take a hypothetical state transportation department running two gateways as a high-availability pair, sharing one configuration and one directory account. Its rebuild touches both devices, and the shared account means one change window covers both. If the same account also serves a wireless controller and a building access system, as such accounts sometimes do, the change window grows to three teams. That discovery is a finding in its own right: an account shared across systems shares their exposure too.

Secrets the gateway’s account can read

The second kind of secret is where the October chain did its distinctive work, and where permissions set years earlier decided the outcome. Volexity reported that UTA0576 used the appliance’s directory account to query Active Directory for four things: LAPS administrator passwords, BitLocker recovery information, password attributes on user records, and the paths of logon scripts. It exported the results. The public account does not say what those queries returned. For any given agency, the answer depended on what that account was allowed to read.

Each target gives an attacker something different, and each calls for a different response.

Local administrator passwords

A LAPS password gives administrator rights on one computer. Read in bulk, the passwords give administrator rights on every computer the account could see. With them, an attacker can move across a network one machine at a time, using legitimate credentials that look like routine support work.

The response is comparatively easy. LAPS can be told to expire passwords early, and each computer then sets a new one at its next policy refresh. For computers on the network, rotation takes hours, not weeks. Laptops that are off the network rotate when they reconnect, so their exposure lasts longer. The prerequisite is knowing that the account could read the passwords at all, and for which parts of the directory.

BitLocker recovery keys

A recovery key is useless over the network. It matters when someone has the physical device, or the ability to tamper with how it starts. That makes it a slower, narrower risk than an administrator password, but a long-lived one. A key read in October can unlock a laptop stolen from a car the following spring, if nobody has changed it.

Rotation is harder. New recovery passwords have to be generated on each device and backed up again, which takes an endpoint management tool, a policy change and time. Across tens of thousands of devices it is a project, not a task. Priority should follow mobility and data: laptops carried by investigators, inspectors and caseworkers, and devices holding tax, benefits or criminal justice data, before desktops that never leave a locked building.

Password attributes

Active Directory has fields that older Unix and application integrations sometimes used to store copies of passwords. In a modern directory they should be empty. Where they are populated, they hold credentials in a form an attacker can read or crack. The response is a reset of every affected account and a cleanup of the fields. That cleanup is overdue directory hygiene whether or not anyone read the fields in October.

Logon script paths

Logon scripts run on users’ computers as they sign in. Their paths tell an attacker where code executes automatically across the organization. If any of those locations can be written to by a broad group, an attacker with the right credentials can plant code that runs for everyone who signs in. The response is to check write permissions on every script location and reduce them to the few administrators who maintain the scripts.

What any signed-in account can do

One more exposure needs no special permission. Any account that can sign in to Active Directory can request service tickets for the accounts that run services, then try to crack weak passwords from those tickets offline. That technique, Kerberoasting, was among the tools Volexity found. So was password spraying, which tries a few common passwords against many accounts. Neither depends on the bind account’s privileges. Both depend on how strong other accounts’ passwords are. Service accounts with long random or system-managed passwords resist the first, and lockout policies and banned-password lists blunt the second.

Finding the scope

A CISO’s first practical task is to produce a list of the secrets this account could read. Directory permission analysis provides it. Attack-path mapping tools, and the directory’s own effective-permission views, show every right the account holds directly or through nested groups. The output is a list of directory locations where it could read LAPS passwords or BitLocker recovery information. That list is the rotation list.

Whether the account actually read those secrets is a separate question, and often an unanswerable one. Domain controllers log reads of specific attributes only where an agency has set auditing rules on the right objects. Where that auditing was in place, the directory holds the best record of how far the attacker reached, better than anything left on the appliance. Where it was not, the agency has to assume that anything readable was read.

Secrets that pass through the gateway

The third kind of secret is in transit. A gateway stands in the path of every remote sign-in and every remote session. Root access to the device means access to whatever crosses it, for as long as the attacker keeps that access.

Volexity found that UTA0576 ran a packet capture tool on the appliance under a misleading name. It collected LDAP and other unencrypted traffic and parsed it for credentials and NTLM password hashes. Two design choices decide how much such capture yields.

The first is how the gateway talks to the directory. LDAP can run unencrypted, in which case a simple sign-in sends the password across the network in readable form. Run over TLS, the same exchange is encrypted. Domain controllers can also require LDAP signing and channel binding, which make relay attacks harder. A gateway still using unencrypted LDAP in 2026 is broadcasting its own directory password, and possibly its users’ passwords, to anyone positioned to listen.

The second is whether the gateway handles user passwords at all. When a gateway checks passwords against the directory itself, every remote user’s password crosses the appliance. When it hands authentication to the agency’s identity provider through a federation standard such as SAML, the gateway receives a signed statement that the user has signed in. It never sees the password. In the first design, multi-factor authentication offers limited protection against a compromised gateway, because the gateway is the component collecting and checking the factors. In the second, an attacker on the gateway can still hijack sessions, but users’ passwords stay out of reach.

Scoping this category means identifying who signed in through the appliance while it was exposed. The exposure window ran from at least October 1, when the first decoy hit was seen, to the moment each agency patched. The gateway’s own logs are the natural source, but UTA0576 edited the appliance’s debug and audit logs, so on-device logs cannot be trusted for this purpose. Logs forwarded off the device as they were written, and sign-in records on domain controllers or the identity provider, are better.

The response is usually tiered. Privileged accounts that signed in during the window get immediate resets and a review of their recent activity. Everyone else gets a reset at a planned point, with closer monitoring until then. A federal component with tens of thousands of remote users cannot reset everyone in one afternoon without swamping its help desk. A county with four hundred can. Both should be able to say which accounts crossed the device, and when.

What a three-day clock can cover

BOD 26-04 sets how fast a federal civilian agency must act on a vulnerability by weighing four factors. They are whether the asset is exposed to the internet, whether the flaw is known to be exploited, whether exploitation can be automated, and how much control it gives an attacker. CISA’s implementation guidance offers, as its example of a three-day due date, a publicly exposed asset with automatable exploitation and total technical impact. The Connect Secure entry received exactly that due date, with a further flag requiring forensic triage.

The guidance lays out what triage looks like across the 72 hours, as recommended practice rather than a mandatory timetable. Within about two hours, the agency scopes the problem and sets up communications that do not rely on possibly compromised systems. Between two and 24 hours, it preserves evidence, collecting volatile data such as memory first. Patching comes after the evidence is collected, because patching can destroy it. Containment follows, done without alerting the attacker. Analysis runs from 24 to 48 hours. By 72 hours, the agency writes a triage report and decides whether to escalate to full incident response.

The report ends in one of three outcomes. With no evidence of compromise, the agency completes remediation, monitors more closely and reviews the episode. With confirmed compromise, it reports to CISA through CISA’s incident reporting system and moves to full incident response. With suspected but unconfirmed compromise, it keeps triaging and coordinates with CISA on whether to escalate.

For this chain, the third outcome is the honest one for many agencies. The attacker installed no backdoor, patched code only in memory, re-exploited the device for each command and edited its logs. Ivanti’s own integrity checker could not see the activity. An agency that captured memory before patching had a chance of finding traces. An agency that patched first, to make Friday’s date, may have erased the only evidence there was. The guidance warns about this ordering problem directly. Meeting it on an appliance requires a memory capture procedure agreed with the vendor or a forensic firm before the advisory arrives.

Seventy-two hours inside one agency

Consider a hypothetical mid-sized federal agency with two Connect Secure pairs, one in each region. The catalog entry lands on Tuesday afternoon. By early evening, the security operations lead has confirmed that both pairs run affected versions and face the internet. She has opened a bridge on phones that do not depend on the agency’s VPN and called the forensic firm on retainer. Overnight, the firm captures memory and disk images from one device in each pair while the partner devices carry the traffic.

On Wednesday, the captured devices are rebuilt and patched, traffic moves to them, and the remaining two are captured and rebuilt in turn. Analysts start on the images. On Thursday, the triage team looks for the request patterns Volexity published and for unusual directory queries from the gateway accounts. The identity team, brought in on Tuesday rather than Friday, has already listed what those accounts could read.

On Friday, the agency files its triage report. If the images show nothing conclusive, the report says suspected but unconfirmed. Its annex shows the bind accounts rotated, LAPS passwords expired across the readable scope and a BitLocker plan scheduled for laptops in the field. The difference between that agency and one that simply patched on Thursday night is mostly decided before Tuesday: a retainer, a capture procedure and an identity team that knows the gateway accounts exist.

Even a perfect triage answers a question about the asset: whether this device was compromised. The implementation guidance does not address credential rotation or service accounts. The catalog has no field for them. The triage report has no section for what the device’s account could read. So the work in the second and third categories of secret runs on no external clock at all.

That gap is not a drafting failure by CISA. A directive can set a deadline for patching a named product, because every agency running the product faces the same fix. It cannot set a uniform deadline for directory permissions, because every agency’s directory is different and the work ranges from nothing to months. The agency has to supply that clock itself, and the natural place to attach it is the triage report. An annex can list the appliance’s stored secrets, the directory rights of its accounts and the users who crossed it. With a rotation status and an owner against each, it turns a question about the device into a question about the incident.

The clock covered one more thing imperfectly. On October 13, the chain’s privilege escalation flaw had no fix. Ivanti chose to ship the fix for the main path rather than wait. Blocking the first link stops an outside attacker from starting the chain, so the choice was defensible. But an agency meeting the Friday deadline had closed the door without closing every weakness behind it, and would be back on the same appliances within weeks.

Federal, state and local: one chain, three jobs

The chain was the same everywhere. The obligations, resources and directory designs around it differed sharply by level of government.

Federal civilian agencies

Federal civilian agencies were bound by the due date and the triage requirement. BOD 26-04 covers federal information systems, including those operated for an agency by another party, so a contractor-run gateway counts. Contractors are not themselves bound unless their contracts say so, and the directive asks agencies to review contracts with their contracting officers. An agency whose managed service provider runs its remote access needs that provider’s memory capture, triage and rotation commitments in writing.

Large departments add a coordination problem. The component that runs the gateway is often not the one that runs the directory. A department-wide directory may be administered centrally while each bureau runs its own remote access. The triage report goes to CISA from one office; the permission review has to happen in another. Departments that assign the directory annex to the identity team, with a deadline matching the triage window, close that gap. Those that leave it with the network team tend to find it never gets done.

Reporting adds a subtler trap. The directive’s reporting runs through agencies’ continuous diagnostics and mitigation dashboards, which show whether a vulnerability remains on an asset. A dashboard that turns green when the gateway is patched says nothing about the directory account’s rights or the secrets the device held. Leaders who read the dashboard as the state of the incident will close it too early.

State agencies

States are not bound by BOD 26-04, though many state security policies use CISA’s catalog as their reference for urgent patching. The distinctive feature at state level is shared infrastructure. Where a central IT agency runs one directory for dozens of departments, a single gateway account’s read rights can span all of them. A LAPS delegation granted at the top of a shared domain years ago may let one department’s gateway account read administrator passwords for computers in every other department.

That turns one department’s incident into an enterprise question, and the state CISO is the person who has to answer it. Personal information in state systems also brings state breach notification laws into view if records were accessed. Whether reading credentials, as opposed to records, triggers any of those laws is a question for counsel, case by case.

Counties, cities and special districts

Local governments face the same chain with far fewer people. A county’s gateway is often installed and run by a managed service provider. The directory account may have been created by that provider with broad administrative rights, because it worked the first time. There may be no in-house capacity to capture appliance memory, and a three-day window can pass while waiting for an incident response retainer to call back.

The useful preparation is mostly contractual and cheap. The county should know who holds the gateway’s administrator access, who can capture memory and how fast, and whether the provider’s directory account is shared across clients’ systems. State resources, where they exist, can help with analysis. Some county gateways carry sheriff’s office or court users who reach criminal justice information. There, the FBI’s CJIS Security Policy also applies, and the county should check its incident obligations with the state agency that administers CJIS access.

Across all three levels, the decisive question has a one-line answer when someone owns it: who is responsible for the gateway’s directory account. Where the answer is a name, the rest follows. Where it is “the network team, probably,” the second category of secret goes unexamined.

The case against rotating everything

The strongest objection to this argument is cost. Volexity described one investigation at one customer, and the attacker there was disrupted. For most agencies, there is no evidence that their gateway was ever touched. Rotating every LAPS password, regenerating BitLocker keys across a laptop fleet and resetting thousands of users’ passwords, on that evidence, looks like a large and disruptive response to a small probability.

The disruption is real. Changing a bind account password at the wrong moment breaks remote access. BitLocker key rotation occupies endpoint teams for weeks. Mass password resets flood help desks and push users toward weaker passwords. October is also a crowded month for public agencies. A new federal fiscal year was under way, and in 2026 a general election was three weeks off for the state and local offices that run it.

A second objection holds that least privilege offers little protection here. Any signed-in account can read most of Active Directory and request service tickets for Kerberoasting. Narrowing a gateway account’s rights, on this view, removes a few attributes from a large exposure.

A third objection is that the answer is a different product. Connect Secure has appeared in CISA’s catalog often enough that some agencies will ask whether to replace it, and some will. Replacement can be the right call, especially for appliances on a branch nearing end of life. It does not remove the directory question. Any gateway, from any vendor, that authorizes users by group needs some way to learn their groups. Cloud-delivered access services usually rely on an identity provider or a synchronization agent that holds directory rights of its own. Whatever replaces the box inherits an account, and with it the same choice about what that account may read.

All three objections have force, and they lead to the same answer: tier the response, and spend the effort on the part that lasts. Secrets stored on the appliance should always be rotated after a suspected compromise, because the work is bounded and stolen values otherwise stay valid indefinitely. Directory-readable secrets should be rotated where the account could read them and the device was exposed before it was patched. User credentials should be reset for privileged accounts first and for others on a schedule.

The heavy, fleet-wide rotation is a symptom of the permission problem rather than a fixed cost of edge incidents. An agency whose gateway account can read LAPS passwords faces the same choice every time a gateway flaw is exploited. An agency whose account cannot read them never faces it. With fourteen earlier Connect Secure and Pulse Connect Secure flaws already in CISA’s catalog, gateway compromise is a recurring event. Fixing the permission once turns a recurring emergency into a routine patch.

On the second objection, the default openness of Active Directory is real, and it explains why least privilege does not stop reconnaissance. It does stop reconnaissance from turning into control. Reading user lists and group names tells an attacker where to go. Reading administrator passwords and recovery keys lets it get there. The protected attributes are protected because they are the dangerous ones, and that is the reason to guard them carefully.

The argument does weaken in one case. Where a gateway already hands authentication to an identity provider, uses a narrowly scoped directory account over encrypted LDAP and forwards its logs off the device, the device-centered response was close to sufficient. Those agencies patched, triaged, rotated a handful of appliance secrets and were done. They had done the directory work years before, which is the whole case for doing it.

Permissions to set before the next edge advisory

The controls that shrink the second and third categories are well understood. What is usually missing is an owner and a date.

• One account per appliance, owned by the identity team. Each gateway, or each high-availability pair, gets its own directory account, recorded with an owner, a purpose and the systems that use it. It is not shared with wireless controllers, printers or applications.
• Read rights matched to the access rules. The account reads users, groups and the few attributes the gateway’s rules use, in the parts of the directory that hold remote users. It belongs to no administrative or help desk group, and it is explicitly denied the LAPS and BitLocker recovery attributes.
• A strong, rotating password. A long random password, changed on a schedule and after every gateway advisory that involves exploitation, with each change recorded.
• Encrypted directory traffic. LDAP over TLS with certificate validation from the gateway, and LDAP signing and channel binding required on domain controllers once dependent systems are ready.
• Federated sign-in where the product supports it. Authentication handed to the agency’s identity provider, so the gateway never handles user passwords and phishing-resistant factors are checked elsewhere.
• Narrow readers for the protected attributes. LAPS set to encrypt stored passwords where the directory supports it, with a small named group able to decrypt them, and BitLocker recovery reads limited to the help desk.
• Auditing on the dangerous reads. Directory auditing set to record reads of LAPS and BitLocker recovery attributes, with an alert whenever a service account makes one, because a gateway has no reason to.
• A memory capture plan for every edge appliance. A procedure agreed with the vendor or a forensic firm and tested once, so that evidence can be preserved before patching inside a three-day window.

Four numbers show whether this is in place, and each can be produced from the directory or the change record.

• How many non-human accounts can read LAPS passwords.
• How many can read BitLocker recovery information.
• How old each edge account’s password is.
• How long, in the last exercise, it took to rotate a gateway’s secrets after a simulated advisory.

An agency CIO who asks for those four numbers will learn more about edge risk than a patch compliance report can show.

What we would tell an agency CISO today is that the October chain is best read as a directory incident that happened to enter through a VPN. The next gateway flaw will carry a different number, perhaps a different vendor, and probably a similarly short clock. How far it reaches will be decided, as this one was, by what the gateway’s account could read the day before the advisory.

With hindsight

Three weeks is a short horizon, and most of what would show whether agencies treated October’s chain as a directory incident is not public. What is public completes the chain itself.

On October 29, Ivanti published fixes for the privilege escalation flaw, now tracked as CVE-2026-111357, and for a further issue, CVE-2026-118527. The second is a weakness in how the appliance generates identifiers, which lets an authenticated attacker upload files to a known location on disk. The fixed releases were 25.1.1.3 and 22.8R2.6. On Friday, October 30, CISA added both flaws to its catalog. It gave federal civilian agencies until November 2 for the privilege escalation flaw, again with forensic triage required, and until November 13 for the file upload flaw, without that requirement. CISA revised its October 13 alert the same day to cover all three.

Agencies that met the mid-October deadline were therefore back on the same appliances within three weeks, with a three-day window that ran over a weekend. Two triage cycles on the same devices in under a month is a fair test of whether memory capture and rotation procedures exist anywhere except on paper.

Both later flaws, as CISA’s catalog describes them, require an authenticated attacker. That supports Ivanti’s decision to ship the main fix on October 13 without waiting: it shut out anonymous attackers. It also meant that between October 13 and October 29, the remaining risk on a patched appliance ran through valid credentials, the very thing UTA0576 had spent its access collecting.

Ivanti also said it had found part of the vulnerability through its own security program, fixed it in its July release, 25.1.3.0, and was backporting the fix to other supported versions when exploitation began. The appliance Volexity investigated ran 22.8R2.4, fully patched for its branch. For agencies, the branch they ran mattered as much as how quickly they patched. CISA’s alert notes that the 22.8 branch reaches end of life on January 31, 2027, so agencies still on it face a migration within months. CISA’s separate directive on end-of-support edge devices, BOD 26-02, exists to move federal agencies off unsupported versions of this kind of device.

CISA did not issue an emergency directive. It handled the chain through catalog due dates and its alert, which is how BOD 26-04 was designed to work. Urgency followed exposure, exploitation and impact, and triage was attached to some entries and not others. The calibration showed in the second round, where the privilege escalation flaw carried the triage flag and the file upload flaw did not.

By early November 2026, the public reporting we reviewed had named no victims, government or otherwise. Attribution rested with Volexity’s low-confidence assessment of a criminal motive. We found no public reporting that put numbers on the indiscriminate mass exploitation researchers had expected. Coverage at the end of October still summarized the actor’s behavior as credential extraction and searches for administrator passwords and BitLocker recovery keys, which is the directory story set out here.

Much remains unknown and may stay that way. No public data shows how many agencies’ gateway accounts could read LAPS or BitLocker attributes, how many triage reports ended as suspected but unconfirmed, or how many agencies rotated anything beyond the appliance. The directive’s 180-day mark, when agencies must remediate within its full timelines, arrives on December 7. The 22.8 branch expires at the end of January. Neither milestone measures directory permissions. That work remains each agency’s own, with no due date unless the agency sets one.