I applied all the patches, but my VPN was compromised

— Ivanti Connect Secure 3-Zero-Day Chain

There are certain things the security team really hates to hear.

“This device is directly exposed to the internet.”

That’s not good.

“It can be attacked without authentication.”

Even worse.

“All currently known patches had been applied.”

My head is starting to hurt.

“They gained root access and wiped the logs.”

I’m definitely not going home today.

In October 2026, an incident was discovered that actually met nearly all of these conditions.

The target was Ivanti Connect Secure, a security device widely used by enterprises as an SSL VPN for remote access.

While investigating a breach in early October, Volexity discovered that an Ivanti Connect Secure device—which had the latest patches applied at the time—had been completely taken over by an unknown attacker.

The investigation revealed that this was not caused by a single vulnerability.

Authentication bypass → Remote code execution → Privilege escalation

It was a zero-day chain consisting of three interconnected stages.

The end result was quite simple.

Internet
   |
   v
Ivanti Connect Secure
   |
   v
Authentication Bypass
   |
   v
Remote Code Execution
   |
   v
Privilege Escalation
   |
   v
ROOT

No user account was required.

A VPN account wasn’t required either.

Furthermore, the device in question was fully patched at the time. Volexity stated that the device under investigation was running version 22.8R2.4, which was the latest version at the time.

Personally, if I had to pick one of the most troubling recent security incidents in an enterprise environment, I’d choose this one.

The reason is simple.

A VPN is, by definition, the gateway into a company’s internal network.

This isn’t just a single CVE incident

The core vulnerabilities that made up this attack chain are currently categorized under three CVEs.

CVE-2026-104935

And there are

CVE-2026-111357

CVE-2026-118527

CVE-2026-104935, which was disclosed first, played a key role in authentication bypass and the remote code execution path.

Subsequently, the privilege escalation vulnerability and the issue related to additional file uploads—which the attacker used in conjunction—were each assigned separate CVEs. On October 29, Ivanti released an additional patch, completing the fixes to block the entire attack chain, and CISA also added the two additional vulnerabilities to its list of Known Exploited Vulnerabilities (KEV).

The CVSS score is not the key point here.

Understanding the attack flow is far more important.

CVE-2026-104935
        |
        v
Authentication Bypass + RCE
        |
        v
CVE-2026-111357
        |
        v
Privilege Escalation
        |
        v
Root Access

This was compounded by an additional file-handling issue exploited during the attack.

Viewed individually, these are vulnerabilities.

When linked together, they form an attack path that goes all the way to the root of the VPN device over the internet.

That’s what makes this chain so dangerous.

It was quite strange from the very beginning.

October 5, 2026.

Volexity began investigating suspicious network activity in a customer’s environment.

Tracing the root cause led to an Ivanti Connect Secure VPN device.

There’s usually one thing we check first in situations like this.

“Has it been patched?”

We check.

But it’s already patched.

It was the latest version at the time.

22.8R2.4
Build 19097

It was.

From this point on, the nature of the incident changes from the security team’s perspective.

If an unpatched server had been compromised, the cause would be clear.

Known CVE
   |
   v
Missing Patch
   |
   v
Compromise

Of course, that’s a major problem in itself.

But what if it was compromised while running the latest patch?

Fully Patched
     |
     v
Compromise
     |
     v
Unknown Exploit

Now we have to consider the possibility of a zero-day exploit.

In fact, the attack activity identified by Volexity had been ongoing since at least October 3. Ivanti publicly disclosed the vulnerability on October 13.

First—access to an authenticated area was gained without authentication

The first step was an authentication bypass.

Ivanti Connect Secure contains CGI scripts related to login that are accessible from the outside, as well as CGI scripts that should only be accessible to authenticated users or internal logic.

This is, of course, how it should be in a normal architecture.

Public Request
      |
      v
Authentication
      |
      v
Protected Handler

However, there was a discrepancy between the frontend—which processes requests—and the backend—which determines the actual destination of the request.

On one side:

“This is a public URL,”

while the other side, based on the information included in the request, could have forwarded it to a different CGI handler that actually required protection.

To put it simply, it’s like this:

To the security guard,

“This person is going to the lobby,”

and

but once inside the building, the elevator takes you to the server room.

Security Check
     |
     | "Public"
     v
Request Router
     |
     | "Protected"
     v
Internal Handler

Different components were trusting the same request based on different criteria.

Personally, I find this vulnerability quite interesting.

It’s not a massive cryptographic attack,

nor is it a memory corruption issue.

Two systems interpret the same value differently.

And in the process, the trust boundary breaks down.

Second—execute the uploaded file before it’s deleted

The next step is even more interesting.

The attacker exploited the logic for processing specific file uploads.

The server first writes the uploaded file to disk.

It then checks whether the file is a valid ZIP file.

If it isn’t valid, it deletes it.

Looking at the structure alone, there’s nothing unusual about it.

Upload
   |
   v
Write File
   |
   v
Validate
   |
   +--> Valid   -> Continue
   |
   +--> Invalid -> Delete

However, there is a problem.

The file already exists on the disk before the check.

It exists for a very brief moment.

The attacker exploited this window of opportunity.

Write
  |
  |<---- Race Window ---->|
  |
Validate
  |
Delete

They send another request simultaneously right after the file is created—before it is deleted—to execute it.

This is a classic race condition.

According to Volexity’s analysis, the attacker rapidly sent multiple execution requests to increase the probability that the payload would execute within this brief window.

What’s interesting here is the server’s perspective.

The server performs its own validation.

It eventually deletes invalid files as well.

However, the validation sequence was incorrect.

Write -> Validate

Or rather, if possible,

Validate -> Trust -> Execute

—that distinction should have been clearer.

In security, even a single step in the sequence is this important.

But it’s still not root.

Even if the attacker succeeded up to this point, all they would gain were the limited privileges of the “cgi-server” user.

So the attacker exploited a third vulnerability.

Privilege Escalation.

Ivanti devices had a privileged background service called “dsinvoked,” which was responsible for executing maintenance tasks with root privileges.

The attacker exploited the fact that this service trusts the task information it receives.

Then, using the code execution privileges they had already secured, they manipulated information in memory and

effectively telling the root service,

"Please run this program."

Result:

cgi-server
    |
    v
Trusted Broker
    |
    v
Root Task
    |
    v
ROOT

The attack code even checked whether it could actually read /etc/shadow to verify if root privileges had been obtained.

At this point, the VPN device is effectively under the attacker’s control.

But is it really such a big deal if just one VPN gets compromised?

It’s a huge problem.

VPNs are typically located here.

Internet
   |
   v
VPN Gateway
   |
   v
Internal Network
   |
   +-- Active Directory
   |
   +-- Servers
   |
   +-- Admin Systems
   |
   +-- Internal Applications

It’s the boundary between the external and internal networks.

And it communicates with internal systems for authentication.

LDAP.

Active Directory.

RADIUS.

Various identity providers.

In other words, a VPN is not simply a piece of equipment sitting in front of the Internet.

It is in an excellent position to view both the internal network and the authentication infrastructure.

Of course, the attacker knew that as well.

What did they do after gaining root access?

The attacker, tracked under the name UTA0576, immediately began searching for internal credentials after taking control of the device.

A Volexity investigation confirmed that the attacker extracted LDAP-related domain credentials stored on the VPN device, retrieved Active Directory metadata, used Kerberos-related tools, and even carried out password spraying.

In particular, there was a rather surprising target.

LAPS Password

And

the BitLocker Recovery Key

VPN Root
   |
   v
AD Service Account
   |
   v
LDAP
   |
   +-- LAPS Passwords
   |
   +-- BitLocker Recovery Keys
   |
   +-- Account Metadata
   |
   +-- Password Attributes

LAPS is a feature designed to securely manage the local administrator password on each Windows device.

However, if an account with the appropriate AD permissions is compromised, an attacker can access that information.

At that point, a compromise of a single VPN device could potentially escalate into an endpoint compromise.

VPN
 |
 v
Credential
 |
 v
Endpoint
 |
 v
Lateral Movement

This is the most frightening aspect in an enterprise environment.

The trust associated with the initially compromised device is more dangerous than the device itself.

Why did they look for the BitLocker key?

This is also quite interesting.

The BitLocker recovery key is originally used to recover an encrypted Windows device in the event of a failure.

In corporate environments, these keys are often stored in Active Directory or Entra ID.

If an attacker were to obtain that recovery key,

the risk of gaining access to the encrypted disk increases—especially when combined with physical or administrative-level access under certain conditions.

In other words, if an attacker simply

“Let’s just steal a few VPN accounts.”

They were not operating at that level.

They were targeting the organization’s entire identity infrastructure.

And they also monitored network traffic.

The attacker also exploited the network location of the VPN equipment.

Volexity also confirmed evidence that the attacker was sifting through packet capture data in an attempt to find credentials in LDAP traffic.

A VPN is an excellent choke point in a network.

Remote User
     |
     v
VPN Gateway
     |
     v
Internal Services

If you can view packets with root privileges here,

you can determine which protocols are unencrypted,

what credential data is being transmitted,

and what internal servers are involved,

you can gather a significant amount of information.

This is one of the reasons why a compromised security device is more dangerous than a regular server.

Security devices are, by design, authorized to monitor others’ traffic.

Why this attack is particularly troublesome—there was no web shell

Usually, when a VPN device is compromised, this is what we look for.

Web Shell
Backdoor
Malware
Persistence

However, the attacker in this case acted unusually.

In the attack analyzed by Volexity, no initial-stage malware or web shell was found.

Whenever the attacker wanted to execute a command, they reran the exploit chain.

Exploit
  |
  v
Run Command
  |
  v
Return Output
  |
  v
Clean Up

And when the next command was needed?

Another exploit.

Exploit
  |
  v
Run Command

There was no need to install a separate C2 implant.

The results of the commands were also delivered via the HTTPS response used by the exploit.

The attacker deliberately

Victim -> C2 Server

create a new network pattern.

From the outside, it may continue to look like regular VPN HTTPS traffic.

It’s quite clever.

They even deleted the logs

The attacker even covered their tracks.

A capability to selectively remove records from the Ivanti runtime log and Linux audit log corresponding to the time of the attack has been confirmed.

The important thing is that they didn’t

rm /var/log/*

Doing that would actually draw more attention.

Why are the logs completely empty?

That’s exactly what would raise a red flag.

Instead, the attacker used a method that removed only the traces of attacks from a specific time period while leaving the existing logs intact.

Normal Logs
Normal Logs
Attack Logs      <- Remove
Attack Logs      <- Remove
Normal Logs
Normal Logs

The result

Normal Logs
Normal Logs
Normal Logs
Normal Logs

looks like this.

From a forensic investigator’s perspective, this is really frustrating.

Even the Integrity Checker couldn’t detect it.

Personally, this was the most interesting part of this incident.

Ivanti has an Integrity Checker tool designed to verify whether a device has been tampered with.

However, this attack might not have been detected even by that tool.

Why?

Because the attacker performed the key manipulations in memory.

During the privilege escalation process, they modified an in-memory copy of the library,

and restored it to its original state once the attack was complete.

The original library on disk remains untouched.

Disk
 |
 +--> Clean

Memory
 |
 +--> Patched
      |
      v
   Exploit
      |
      v
   Restore

What if the Integrity Checker detects a disk modification?

Disk: Clean

it will display a warning.

But the device may already have been compromised.

Volexity also explained that, in the case of this attack, the Integrity Checker alone cannot confirm a compromise; memory and network forensic analysis are required.

This is a very important point.

“Scan result: Clean” does not mean “not compromised”

There is a common misconception in incident response.

Scanner: Clean

This leads to

System: Safe

people tend to think that

The two are not the same.

No Evidence Found
        !=
No Compromise

This incident is a perfect example of that.

There are no files.

There’s no web shell either.

The integrity check is normal.

Some logs were also deleted.

Yet the attacker had root access.

That’s why, in Incident Response, we always ask:

“Is the Evidence Source I’m looking at actually reliable?”

On a system compromised by an attacker with root privileges, you should never trust that system’s logs 100 percent.

We patched it, but then we had to patch it again

This is particularly frustrating from the operations team’s perspective.

On October 13, Ivanti released a patch for CVE-2026-104935.

The security team schedules an emergency task.

Since it’s VPN equipment, scheduling a maintenance window isn’t easy.

We notified users,

verify HA,

verify backups,

and perform updates.

Done.

...or so I thought.

However, as additional fixes were released for the remaining vulnerabilities used in the attack chain, some environments that had already been patched had to be updated again.

According to SecurityWeek, the additional fixes released on October 29 addressed CVE-2026-111357 and CVE-2026-118527, and Ivanti stated that the latest release resolves the entire vulnerability chain used in actual attacks.

Anyone who’s worked in security operations knows just how painful this is.

Emergency Patch
      |
      v
Change Request
      |
      v
Maintenance
      |
      v
Validation
      |
      v
Done

I went to bed thinking,

New Advisory
      |
      v
Patch Again

that’s it.

That’s why you can’t just look at the CVSS score

CVE-2026-104935 had a CVSS score in the 8s.

Based on the number alone, it might seem less dangerous than a CVE with a score of 9.8 or 10.0.

But in reality,

Actively Exploited
        +
Internet-facing VPN
        +
No Authentication
        +
Root Privilege
        +
Credential Access
        +
Anti-forensics

was attached.

This is something I consider quite important in vulnerability management.

CVSS
 !=
Risk

The actual priority

Exploitability
Exposure
Asset Criticality
Active Exploitation
Privileges Obtained
Business Context

factors like this must be taken into account.

A CVSS 8.8 zero-day vulnerability in a VPN exposed to the internet

may be more urgent than a CVSS 10.0 vulnerability on an internal test server.

This is why you shouldn’t determine the patch queue based solely on numbers.

Why Do VPN Devices Keep Getting Compromised?

This isn’t just an issue specific to Ivanti.

In recent years, attackers have consistently targeted network edge devices.

VPN
Firewall
Load Balancer
Email Gateway
Remote Access Appliance

That’s because they make such easy targets.

First,

They are exposed to the internet.

Second,

They are connected to the company’s internal network.

Third.

Has high privileges.

Fourth.

It communicates with authentication systems such as LDAP or AD.

Fifth.

Unlike general servers, EDR is often not installed on these systems.

Structurally, this is bound to be appealing to attackers.

Internet-facing
      +
Trusted Network Position
      +
High Privilege
      +
Limited Endpoint Visibility

From an attacker’s perspective, this is a very attractive combination.

The absence of EDR is a bigger issue than you might think.

Let’s say an attacker carries out this kind of activity on a standard Windows server.

PowerShell
Credential Dumping
Network Recon
Persistence

EDR is likely to trigger various alerts.

However, VPN appliances are often closed systems provided by the vendor.

You can’t just install CrowdStrike or Defender as you please.

As a result, the security team’s visibility is limited.

Vendor Logs
Network Logs
SIEM
External Telemetry

In this particular attack, however, even the vendor logs themselves were tampered with.

This makes network telemetry even more important.

If our company uses Ivanti, what should we look for?

The first thing to do is, of course, to check whether the version you’re currently using is secure based on the vendor’s latest advisory.

Ivanti recommended that affected customers update immediately and announced that the full attack chain used in the actual attack had been fixed in an additional release at the end of October.

The next step is even more important.

You shouldn’t assume that the incident response is over just because the patch has been applied.

If the equipment was exposed to the internet during the vulnerability window,

Patch
   |
   v
Investigation

you should proceed as follows.

If an attacker has already gained access, the patch prevents future attacks,

it does not eliminate past breaches.

For a senior security team, the questions are different.

In the early stages, they ask questions like these:

Is this a vulnerable version?

Next,

Has it been patched?

This falls under Vulnerability Management.

Incident Response goes a step further.

Is there any evidence of exploitation prior to the patch?

What credentials were used to access the internal AD from the VPN?

What is the scope of that service account’s permissions?

Were we able to read LAPS or BitLocker attributes?

Is there any evidence of lateral movement originating from the VPN?

Was there any password spraying during the same period?

Are there any sections where the authentication logs were abnormally interrupted?

The questions evolve like this.

Is it vulnerable?
      |
      v
Was it exploited?
      |
      v
What did the attacker access?
      |
      v
What trust did the device have?
      |
      v
Where could they move next?

This is the process of determining the blast radius of an actual incident.

Personally, the most important lesson from this incident

It’s also interesting that three zero-days were chained together.

The race condition is also interesting.

It’s also interesting how they bypassed the integrity checker using a memory patch.

However, I believe the most important point from an enterprise security perspective lies elsewhere.

Security devices themselves are part of the attack surface.

We often think of VPNs as security solutions.

Firewalls are also security solutions.

Email gateways are also security solutions.

That’s why we tend to trust them instinctively.

Internet
   |
   v
Security Device
   |
   v
Trusted Network

However, the structure looks different from an attacker’s perspective.

Internet
   |
   v
High-value Target
   |
   v
Trusted Network

It’s the same picture.

Because these devices were installed for security purposes, they actually

it enjoys higher trust and a more privileged network position.

If that trust falls into the hands of an attacker, the damage will be even greater.

And here’s the most alarming statement:

If I were to summarize this incident in one line, it would be this:

Fully Patched VPN
       |
       v
Unauthenticated Exploitation
       |
       v
Root Access
       |
       v
Credential Theft
       |
       v
Anti-Forensics

“They got hacked because they didn’t apply the patch.”

The solution is relatively simple.

Just fix the patching process.

However,

“All the patches were applied, but we still got hacked.”

then it’s a different story.

From that point on, what’s needed is

not just Patch Management, but also

Network Monitoring,

Identity Security,

Credential Hygiene,

segmentation,

Incident Response,

Memory Forensics,

Detection Engineering

All of them.

In the end, I find myself repeating the obvious phrase: “Defense in Depth.”

It’s a cliché,

but when I see situations like this, I think I understand why it’s become such a cliché.

Finally,

Ivanti stated that the attacks were confirmed in a limited number of customers and released an additional patch in late October to address the entire attack chain. CISA also listed the additional vulnerabilities actually exploited in the attacks on the KEV.

So, the main point of this post is

“If you use Ivanti, you’re in big trouble.”

is not the point.

Rather, what I found interesting about this incident was

how the attacker exploited the structural positioning of the security equipment.

They bypassed authentication,

executed code within a short race window,

escalate privileges to root,

exploited the VPN’s Active Directory trust,

wiped logs,

and leave as few traces as possible on the disk.

Taken one by one, these are all familiar techniques.

But when you put them all together, it’s pretty scary.

And ultimately, the most important aspect of practical security is similar.

It’s not about looking at a single vulnerability,

Entry Point
    |
    v
Privilege
    |
    v
Trust
    |
    v
Credential
    |
    v
Lateral Movement

but looking at the entire chain.

I think this recent Ivanti incident is a case that illustrates this point very well.

You shouldn’t trust security devices just because they’re security devices.

In fact, the more specialized the security device,

“If this gets compromised, how far could an attacker go?”