Skip to content
Start with Identity
Analysis

Remote access appliances are credential vaults, so patch day has to be rotation day

Four October disclosures about BeyondTrust, Ivanti and Fortinet gateways all ended the same way: the attacker left with the credentials the box was holding. A patch closes the door, but the passwords, keys and certificates that walked out stay valid until you rotate them.

By SWI Community TeamOct 20, 2026

Remote access gateways and support appliances are credential stores with a login page in front. In four October 2026 disclosures, about a BeyondTrust support appliance, an Ivanti VPN, compromised FortiGate firewalls and a FortiBleed credential campaign, the attacker's real prize was what the device held: vaulted admin passwords, LDAP bind accounts, VPN user credentials and private keys. Patching ends the intrusion path. It does nothing about secrets that have already left, which is why every one of these advisories ends with a rotation list.

Key takeaways

  • An appliance that brokers access holds credentials for everything behind it, and usually the policy that says who may use them.
  • After compromise, the appliance's own logs are not evidence. Two of the four attackers removed or edited them.
  • "Patched" and "remediated" are different states. Remediation is rebuild, then rotate in dependency order.
  • Every gateway needs a written list of the secrets it stores, kept current, so rotation can start the day the advisory lands.
  • Phishing-resistant MFA on admin and VPN sign-in turns a recovered password from a login into a dead end.

What each box was holding

Appliance Way in What the attacker took
BeyondTrust Remote Support (self-hosted) CVE-2026-102764, unauthenticated file operations Every administrative credential in the appliance vault, then admin roles over downstream sessions
Ivanti Connect Secure CVE-2026-104935, auth bypass with a crafted header Stored domain credentials used for LDAP, then Active Directory secrets
FortiGate via FortiManager CVE-2024-47575, then CVE-2025-61624 Configurations for more than 500 firewalls, including VPN credentials and private keys
FortiGate (FortiBleed) No CVE: reused and cracked passwords Admin and VPN access, resold to ransomware affiliates

BeyondTrust. Google Threat Intelligence and Mandiant attribute the zero-day use of CVE-2026-102764 to ARMORY CASTLE, formerly UNC5221, from late August. After a web shell and a root SUID backdoor, the actor ran the appliance's own bt-secrets tool to dump the vault, including the appliance-level password safe. It then signed in to the admin portal as a real administrator and raised its Jump Item and Team roles from No Access to Administrator. Downstream sessions looked like ordinary brokered admin work. BeyondTrust patched SaaS tenants on October 9, and CISA added the flaw to its Known Exploited Vulnerabilities catalog on October 16. Our CVE-2026-102764 brief has the detail.

Ivanti. Volexity saw UTA0576 exploiting CVE-2026-104935 from October 3, chained with a privilege escalation flaw that has no fix yet. No web shell, no backdoor. The actor pulled LDAP domain credentials stored on the appliance, used a compromised service account to search Active Directory for LAPS passwords and BitLocker recovery keys, captured LDAP traffic to harvest plaintext credentials and NTLM hashes, and ran Kerberoasting and password spraying. Ivanti's Integrity Checker Tool saw nothing, because the escalation patched code in memory only. See the CVE-2026-104935 brief.

PEERSTITCH. Unit 42 at Palo Alto Networks found a memory-resident implant inside FortiOS's IKE daemon at a telecom managed service provider. A VPN session carrying the implant's tag takes a branch that skips default security validations. The archive the actor took held running configurations for more than 500 managed FortiGates, with admin and SSL VPN credentials stored as reversible ciphertext that Unit 42 confirmed could be recovered, plus certificates and private keys. CISA added CVE-2025-61624 to KEV on October 16 with an October 19 deadline.

FortiBleed. A joint FBI and Secret Service advisory, JCSA-20261006-01, on October 6 said the campaign is still using stolen credentials against exposed FortiGates, and sometimes locks owners out by deleting or changing their admin accounts. It cites SOCRadar's verification of more than 86,644 compromised devices across 194 countries. There is no vulnerability: reused passwords, leaked credentials and legacy SHA-256 password storage were enough.

Why these devices are worse than an ordinary server

A file server that gets owned leaks files. A remote access appliance that gets owned leaks the means to log in elsewhere, and three properties make it worse.

It holds other systems' credentials by design. A support appliance injects vaulted passwords into sessions. A VPN binds to the directory with a service account so it can check group membership. A firewall stores local users, VPN users and the certificates that prove the tunnel is real. None of that is a misconfiguration. It is the job.

It is also the judge. BeyondTrust's role table decides who may open a session to which machine. PEERSTITCH decides which VPN sessions get checked. Once the attacker controls the policy as well as the secrets, the access that follows is indistinguishable from authorized work, which is the core idea behind privileged access management turned against itself.

It is a poor witness. ARMORY CASTLE deleted the appliance's auth, HTTP and bt-secrets logs. UTA0576 selectively edited Ivanti's logs. Only telemetry that left the device before the intrusion, such as forwarded syslog, firewall flows and directory sign-in logs, can be trusted afterward.

Patch day is rotation day

Every advisory above converges on the same order of work. Write it down for each appliance you run before you need it.

  1. Preserve, then rebuild. Snapshot with memory where you can, then rebuild from a clean, patched image. Mandiant and CISA both advise against cleaning in place.
  2. Rotate the appliance's own admins first, so the attacker cannot watch the rest of the rotation from inside. For FortiBleed, confirm you still hold a working admin account and look for the rogue account names in the advisory before resetting anything, or the reset can lock you out instead of them.
  3. Rotate what the appliance used to talk to the directory: LDAP bind accounts, SAML signing keys, API account secrets. Then reset Kerberoastable service accounts, because UTA0576 showed that is where a VPN foothold goes next.
  4. Rotate everything the appliance could hand out: vaulted credentials, VPN user passwords, local accounts. Reissue VPN and admin certificates and revoke the old ones. Unit 42's guidance is to treat the trust material on a compromised management platform as compromised until rotated.
  5. Diff the policy. Compare role assignments, admin accounts and API keys against a baseline from before the exposure window. BeyondTrust's role escalation would survive any number of password changes.
  6. Close the reuse path. Put admin and VPN sign-in behind phishing-resistant MFA, restrict admin interfaces to management networks, and on FortiOS move admin password storage to PBKDF2.

Questions to ask of every gateway you run

  • Which credentials does it store, and could we list them today without logging in to it?
  • Which directory or vault accounts does it use, and what else can those accounts read?
  • Are its logs forwarded off the box in real time, and do we alert on gaps?
  • Who can change its access policy, and would we notice a role going from No Access to Administrator?
  • If we had to rotate everything it holds by Friday, who owns each step?

If the answer to the first question is "we would have to check the appliance," that is the work. An inventory of what the box holds is the difference between a rotation that starts the morning the KEV entry appears and one that starts after the incident response firm has finished.

Last reviewed By SWI Community TeamSuggest a correctionHow we research
Independent analysis. No vendor sponsorship.