Ivanti Connect Secure: how an authentication bypass and RCE turned a VPN into an entry point

As of 10 January 2024, affected Ivanti Connect Secure and Ivanti Policy Secure gateways were required to apply the mitigation published by Ivanti, and to install the fix once it was released. The reason was stated directly: CVE-2023-46805 and CVE-2024-21887 were being exploited in combination, which allowed a remote attacker to bypass authentication and execute arbitrary commands on the device.

The practical meaning of that requirement goes beyond installing a fix. By the time the advisory was published, exploitation was already under way, and Volexity documented the web shells, file modifications and post-access activity found on compromised VPN gateways. Two tasks therefore have to be kept apart: closing the vulnerable path, and establishing whether that path had already been used.

What was visible from the outside before the attack

The first element of the chain was an internet-facing VPN gateway. That is not a side effect and not a symptom of compromise: remote reachability is what such a node is for. In the attack described by Volexity, the object of exploitation was an Ivanti Connect Secure appliance accepting external connections.

This is the step that could be seen before the breach. Identifying it required no device logs, no indicators of compromise and no knowledge of the attacker's actions. It was enough to establish that the VPN service was published on the external perimeter, and that it belonged to a product for which Ivanti had reported active exploitation of two vulnerabilities.

Practical reading: a line in the asset register saying that a VPN exists does not by itself answer the question of risk. What is needed is confirmation that the gateway is actually reachable from outside at the present moment. The distinction matters for devices that may have been published after the inventory was taken, returned to the network, or exposed at an address the register does not link to the expected owner.

This is where control of the external perimeter comes in. Continuous scanning first finds the internet-facing service, and prioritization by exploitability separates it from the rest of the discovered systems: Ivanti stated that CVE-2023-46805 and CVE-2024-21887 were used in real-world attacks. Priority here is set not only by the severity of the individual defects, but by three conditions together: the service is reachable from the internet, the vulnerabilities form a working chain, and exploitation is confirmed.

Step 1. Authentication bypass

CVE-2023-46805 affects the web component of Ivanti Connect Secure and Ivanti Policy Secure. According to Ivanti's description, the vulnerability allows a remote attacker to bypass authentication checks and reach restricted resources.

This is the first transition in the chain. Access to a login page on its own does not amount to administrative access. CVE-2023-46805 changed that condition: a request could reach a resource that, in the intended model, should have been protected by an identity check.

Practical reading: multi-factor authentication for VPN users does not break the chain described here. The vulnerability was in the web component of the gateway itself and allowed the gateway's own authentication check to be bypassed. This is not a conclusion that multi-factor protection is useless in general; it is the boundary of its applicability in this incident. A user-level control does not substitute for fixing a defect in the device that implements that control.

Step 2. Command execution

CVE-2024-21887 is a command injection vulnerability in the web components of the same products. In Ivanti's description, exploiting it requires authenticated administrative access.

Taken separately, that requirement lowers the vulnerability's reachability for an external attacker. In the chain it stops being a barrier: CVE-2023-46805 allows authentication to be bypassed, after which CVE-2024-21887 makes command execution possible. Ivanti describes the outcome of the chain as execution of arbitrary commands without authentication.

This is why assessing each CVE in isolation falls short. The authentication requirement of CVE-2024-21887 could look like a compensating condition. CVE-2023-46805 removes precisely that condition. For prioritization on the external perimeter, the unit of assessment should be the pair of vulnerabilities on one reachable gateway, not two independent entries in a list.

Step 3. Activity on the gateway

Once command execution was available, the attacker moved from exploiting vulnerabilities to working inside the device. Volexity found command execution, data collection and modifications on compromised systems. The report also describes the placement of web shells and changes to gateway files.

At this stage the VPN can no longer be treated only as a means of carrying traffic to internal resources. Code was running on the edge device itself. Any further check therefore has to cover not only user connections through the VPN, but also the state of the gateway's file system, configuration and components.

Practical reading: successfully blocking later requests to the vulnerable route does not answer the question of whether an access mechanism placed earlier is still present on the device. Closing the initial entry point and removing its consequences belong to different stages of response.

Step 4. Persistence

Volexity described web shells installed on compromised Ivanti Connect Secure appliances. A mechanism of this kind changes the logic of subsequent access: the attacker no longer has to pass through the original vulnerability chain again, as long as the component left behind keeps accepting commands.

This is where the formula “the patch is installed, so the incident is closed” stops holding. A fix is meant to remove the vulnerable path. It does not prove that the path was not used before the fix was applied, and it is not in itself the result of a check on the state of the device.

In Ivanti's guidance, checking for compromise is kept separate from applying the mitigation and the fixes. The Integrity Checker Tool is provided for that check; where signs of compromise are found, Ivanti points to the need to restore the device to a factory state before returning it to service and applying the fixes.

Practical meaning: the absence of further CVE exploitation after the patch is installed is not a negative investigation result. A separate basis is required to consider the gateway clean. For a device that was already affected, a new patch level alone cannot be that basis.

Where the chain broke at the lowest cost

The earliest point of control was ahead of the attacker's first request: identifying an internet-facing Ivanti Connect Secure and matching it against a pair of actively exploited vulnerabilities. At that stage there was no need to hunt for web shells or rebuild the device. What was needed was to shorten the time between Ivanti publishing the information and the prescribed mitigation or fix being applied.

The next point is checking the gateway after exploitation was reported. It costs more, because it involves looking for traces and allows for rebuilding the device. Even so, it still breaks the chain before retained access is taken for the normal state of an already patched system.

Monitoring changes on the external perimeter addresses a separate risk. A one-off check shows that the gateway was reachable at the moment of the check. It does not reveal that the device was later returned to the network or published again. If a VPN appears on the outside after a patching campaign has run, the initial condition of the chain arises for it anew: an internet-facing service whose state has to be matched against Ivanti's current requirement.

The limits of the conclusion should also be stated. External scanning shows that an entry point exists and makes it possible to set its priority. It does not establish the absence of compromise inside the device. That task is handled by integrity checking, analysis of the artifacts Volexity described, and the restoration procedure Ivanti provides when signs of interference are found.

Where the chain could have been broken

Each requirement below is paired with the action that answers it.

• From 10 January 2024: apply the mitigation published by Ivanti to affected gateways, then install the available fix — find every internet-facing Ivanti Connect Secure and Ivanti Policy Secure, determine their state, and apply the measure from the Ivanti advisory
• From 10 January 2024: account for the joint exploitation of CVE-2023-46805 and CVE-2024-21887 — prioritize the internet-facing pair as one chain of authentication bypass and command execution, instead of assessing the CVEs in isolation
• After an external gateway is identified: establish whether it was compromised before the vulnerabilities were addressed — run the integrity check Ivanti provides and look for the modifications and web shells Volexity described
• If signs of compromise are found: do not stop at installing the patch — carry out the factory-state restoration Ivanti prescribes, then apply the necessary fixes before returning the device to service
• After the initial inventory: keep track of changes in reachability — monitor new and re-published VPN gateways and match them again against information on active exploitation