They Installed Nothing At All

Attackers took complete control of a company's remote-access appliance, helped themselves to the passwords stored on it, and installed nothing at all. Antivirus had nothing to find. The vendor's own tamper check said the device was fine. Two of the three flaws now have a patch.

On October 13 the security firm Volexity published what it had found two weeks earlier inside a client's network. Attackers had taken complete control of the box that lets staff log in from outside, and they had installed nothing at all. Our interest, up front: we deploy Ubiquiti UniFi gateways, and equipment at the edge of a network gets security advisories — ours included. Most firms our size do not run the appliance in this story. We are writing about it because the lesson is not about the brand. The technical part — you can skip this box *Volexity, "A Series of Unauthenticated Events: Chained Exploitation of Ivanti Connect Secure Zero-Days," published October 13, 2026, by Charlie Gardner, Sean Koessel, Steven Adair and the Volexity Volcano Team. Volexity reports that starting October 3, 2026, an actor it tracks as UTA0576 chained three previously unknown flaws in Ivanti Connect Secure to reach unauthenticated root-level code execution: an authentication bypass, a file-write flaw producing remote code execution, and a privilege-escalation flaw. The first two are tracked together as CVE-2026-104935 — a catalog number, like a case number — and Ivanti released patches for them on October 13, 2026. The privilege-escalation flaw carries no catalog number in the post and is not yet fixed ; Volexity says Ivanti is working on it for a future release. Volexity opened its investigation on October 5 at a network security monitoring customer and reconstructed the chain from memory images, disk images and core dumps. It reports "no backdoor or web shell deployed to the compromised device" and no first-stage malware; the actor deleted entries from two log files; and because the chain patched code only in memory and restored configuration data, Ivanti's Integrity Checker Tool "does not detect any modifications." On the appliance the actor collected stored credentials including directory-service domain credentials, exported directory contents, searched for stored local-administrator passwords, disk-encryption recovery keys and other password-bearing fields, captured directory traffic and sprayed passwords. Volexity advises patching, watching for unusual volumes of requests to one specific sign-in page carrying malformed headers, checking the temporary-files directory for leftovers, and running memory and network forensics where compromise is suspected, because the Integrity Checker "may not be able to identify device compromise." * On versions, and the direction matters: Volexity lists "25.1.1 and prior," "25.1.2," and "22.8R2.4" among releases to upgrade — "and prior" means the lower-numbered releases are the affected ones, not the higher. Rapid7 and BleepingComputer, both reporting October 13, give the affected lines as 22.8R2.4 and earlier, 25.1.1.1 and earlier, and 25.1.2.2 and earlier, with 22.7 and below unaffected. Fixed-version numbers are deliberately not printed here: Ivanti's own advisory page would not open for us, and the secondhand accounts of it do not agree with one another. What that actually means They used three bugs, not one. None was enough alone. The first let a request past the login screen. The second let the attacker write a file onto the machine. The third turned that into the machine's top-level account. Two now have a patch. The third does not. No password was needed. Nothing had to be guessed, phished or stolen to get in the first time. They installed nothing. No virus, no hidden program, no remote-control tool. So antivirus has nothing to find, and the honest answer to "did the scan come back clean?" is yes, it did. The vendor's own tamper check agreed. It is a tool whose whole job is answering "has this device been altered?" Volexity's finding is that it "does not detect any modifications." What they took was passwords. A remote-access box has to store credentials so it can check who is signing in, and those are usually credentials for the rest of the network. That is why the attacker went straight on to the company directory, looking for more. The part that should change a question you ask When somebody tells you a device may have been broken into, the usual first question is "is there anything on it?" This is the clearest example in a long time of why that is the wrong one. There was nothing on it. The damage had already left as passwords. What to do, and the order is the point Patch it. If you run a remote-access appliance of any brand, this is a patching week. Use the version your vendor names for your release line. Then change what it knew. Every account that box could see, service accounts first. This is the step that gets skipped, because patching feels like finishing. Then look. Not before. Looking first tells you only what the tools can see, and this week the tools saw nothing. If we manage your network, call before you start changing passwords. Service accounts break things when they are changed in the wrong order, and that is a cheaper phone call than the alternative.