They broke into a fully patched appliance and went for the recovery keys

On 13 October, Volexity published its analysis of an intrusion into an Ivanti Connect Secure remote access appliance. The technical headline fits in one line: by chaining three separate flaws, an attacker they call UTA0576 achieved unauthenticated root-level code execution on a device the report describes as "fully patched (22.8R2.4, Build 19097)". Volexity places the exploitation since at least 3 October; detection outfit Defused says it saw the first attempts on the 1st. The fix shipped on the 13th: between ten and twelve days.

If you do not run that product, the easy move is to scroll past. We do not sell or deploy it either. The value of this report lies elsewhere: it is one of the few that walks through, step by step, what the attacker did once inside. And that list, read slowly, is not an inventory of credentials. It is the table of contents of your recovery plan.

Three flaws, one CVE, and one still unfixed

The chain has three links: an authentication bypass in welcome.cgi, which allows routing to protected CGI files; a remote code execution in wu.cgi, a file write with a race condition; and a privilege escalation through the trust mechanism by which dsinvoked reads its DSCache-stored configuration. The first two travel together under CVE-2026-104935, which is what was patched on 13 October in versions 22.8R2.5, 25.1.1.2, 25.1.3.0 and 25.1.3.1. The third, the privilege escalation, had no CVE assigned when the analysis was published and still has no fix: per Volexity, Ivanti is working on it and it will ship in a future release "in the coming weeks".

That detail alone already breaks any vulnerability management process: a link in an actively exploited chain that shows up in no feed, because it has no identifier to track. Your scanner cannot tell you anything about something that does not exist in the catalogue.

No backdoor, no web shell

This is the part that changes the defensive reasoning. Per Volexity, UTA0576 "passed commands and results through the exploit chain's HTTPS requests rather than a separate command-and-control (C2) channel, with no backdoor or web shell deployed to the compromised device". No backdoor. No web shell. No separate command channel for an egress firewall to find odd. And for every command they ran, the report says, "the entire exploit chain is executed": they came back in from scratch, once per command.

The cleanup was not a blunt wipe either. The code read the two logs that matter — /home/runtime/dlogs/debuglog and /var/log/audit/audit.log — filtered out the entries inside the window they had been active, and rewrote the files with the rest. There is no obvious gap and no zero-length file, just a perfectly plausible log missing a few minutes nobody goes looking for.

It is worth not overstating it, because the report itself bounds the claim: artefacts were left, which is why Volexity recommends checking the /tmp/ directory and hunting for requests to /dana-na/auth/url_default/welcome.cgi with suspicious X-DSCGI-PATH headers. Invisible they were not. What they left, though, sits in places no routine review procedure ever looks at.

The tool meant to tell you says it is clean

The vendor publishes a utility, the Integrity Checker Tool, whose job is precisely this: spotting unexpected modifications to the appliance's files. Volexity puts it plainly: "because this exploit chain patches library code in memory only and restores configuration store data, the tool does not detect any modifications". CISA repeated it the same day in its alert, just as bluntly: the tool "may not detect evidence of exploitation of CVE-2026-104935 because threat actor commands execute in memory", which is why it recommends network and memory forensics for anyone who suspects they were hit.

And in that same week, the vendor's advice to customers was still to review the advisory, upgrade as soon as possible and "run the Integrity Checker Tool regularly". Both things can be reasonable at once — the tool still has its uses — but they have to be read together, because the practical conclusion is uncomfortable: a clean result from that tool is not an answer. It is the absence of one.

We are writing that correction down, because our default advice, and half the industry's, after an advisory about a closed appliance is "run the vendor's integrity checker". Here that step closes nothing. And the memory forensics that would close it requires access you do not have on a closed appliance, and tooling almost no small company owns. Between "no evidence" and "no way to have evidence" lies the whole distance between closing an incident and filing it without knowing.

LAPS, BitLocker and a tool they never used

That they took LAPS passwords and BitLocker keys has been in every piece of coverage this week; it is not our finding and it is not hidden. What almost nobody has said is what kind of material that is. To get there you have to look at the whole post-exploitation list Volexity documents:

• They extracted the domain credentials of the LDAP service account the appliance uses to query the directory.
• They deployed a Python LDAP tool searching, literally, for LAPS passwords, BitLocker recovery information and Active Directory attributes carrying userPassword and unixUserPassword values.
• They also uploaded a custom Python Kerberos implementation with Kerberoast functionality which, Volexity says, the calling script never used. They had the capability and prioritised something else.
• They ran packet captures filtered for plaintext protocols such as LDAP (TCP 389), HTTP, FTP or telnet: that is where unencrypted credentials still travel on a corporate network.
• They attempted to extract valid usernames from the appliance's own authentication logs (log.events.vc0), and used them for password spraying against the directory.
• And they exfiltrated Active Directory metadata and the appliance configuration.

LAPS passwords are the local administrator passwords of every machine: the ones you use when a box will not boot into the domain. BitLocker keys are recovery keys: the ones you use when a disk will not mount. Neither is any use for getting work done on an ordinary Tuesday; both are the material you recover with once something has already gone wrong. And they were the first thing somebody asked the directory for as soon as they had the rights to ask, with a Kerberos attack sitting there unused.

Your plan is written against deletion

A normal continuity plan measures one thing: how long it takes you to have back what you lost. RTO, RPO, immutable copies, off-site replication, restore drills. The whole conceptual apparatus is built against destruction: something is deleted, encrypted, broken, and you put it back.

Copying destroys nothing. A copy does not take a service down, does not fire an availability alert, does not open a ticket, does not consume RTO and does not activate any plan. Your BitLocker recovery keys are still there after somebody takes them: they work just as well, for you and for them. That is exactly why this scenario appears in almost no continuity plan we have read, including the well-built ones and the continuity plan nobody has rehearsed: there is nothing to restore, so there is nothing to rehearse.

And there is a second clock running. European notification duties — NIS2 for those in scope, with its 24-hour early warning, and the GDPR with its 72 if personal data is involved — start when you become aware of the incident, not when the incident happens. It is the same mechanism we wrote about around the Cyber Resilience Act: the clock starts when you find out. Here the tool designed to make you aware is documented, by the vendor and by CISA, as unable to notice. Who then decides that you have "become aware", and on what evidence, is not a question you answer well at eleven o'clock on a Tuesday night.

The missing inventory: what happens if it is copied

What you can do this week, without buying anything, is a two-column inventory. On the left, what passes through your remote access. On the right, the question no backup audit asks: not "what happens if it is deleted", but what happens if it is copied. These four rows are where you start:

The third column is missing, and it does not fit in the table because it is a proper name: who rotates each of those four things, and how fast. The point of the exercise is to be able to say, the day an advisory tells you your remote access box was exposed and you cannot prove anything, what you treat as copied and what you rotate, without calling a meeting to decide it. If filling it in reveals that nobody knows which service account the appliance uses, that is already the result and it was worth the time.

Two calendar notes to close the operational side. The procedure CISA publishes for anyone who suspects ends with "Reset all passwords and revoke/reissue certificates and API keys", which is exactly the right-hand column above; we saw that same tension between restoring and rotating from the other side this morning: GitLab's official recovery procedure starts with a DELETE. And the alert adds one detail worth checking before celebrating the upgrade: the 22.8 branch reaches end of life on 31 January 2027, so leaving via 22.8R2.5 buys three and a half months.

What stays on the record

The box that faces the internet by design is, nearly always, the one you can audit least: you do not install an agent on it, you do not read its memory, you do not log into a console to inspect a process. We wrote a few days ago that only one in eight exploited flaws sits in an appliance — few in the count, enormous in the consequences. This case adds the why: when the flaw lands there, what the attacker walks away with is not a server, it is permission to ask your directory questions. And the directory answers all of them, including where you keep the spare keys.

Sources (checked 14 Oct 2026): the three-flaw chain, the affected components, the 22.8R2.4 Build 19097 figure, the "since at least 3 October", the sentence about the absence of a backdoor and command channel, the per-command re-execution of the chain, the two tampered log paths, the Integrity Checker Tool limitation and the whole post-exploitation list — including the LAPS passwords and BitLocker keys — come from Volexity's 13 October 2026 analysis. CISA's warning about the tool, the network and memory forensics recommendation, the recovery procedure and the 22.8 end of life are in its 13 October alert; the catalogue addition, in the alert of the same day. The fixed versions and the status of the third flaw are reported by SecurityWeek, and the vendor's advice to keep running the integrity checker, by BleepingComputer. One caveat the report itself flags and we repeat: Volexity attributes a criminal rather than espionage motivation with low confidence, and the attacker's use of language models with medium confidence; those are assessments, not facts. And one naming caveat, in case you go to the official source: the KEV catalogue titles CVE-2026-104935 only as an Authentication Bypass by Spoofing Vulnerability, while Volexity and the trade press present it as covering the code execution too. We have not reproduced the chain, we do not deploy that product and we have no telemetry of our own on its exploitation. What is ours is reading the post-exploitation activity as the index of a recovery plan, and the "what happens if it is copied" table.