Free tools Windows power users keep installed
One-click scans. No signup required.
The Ivanti VPN incident was not one bug but a two-step exploit chain. CVE-2023-46805 let an attacker bypass authentication and reach protected functions without logging in. CVE-2024-21887 then let the attacker inject commands through crafted requests. Together, the flaws enabled unauthenticated remote code execution on Ivanti Connect Secure and Ivanti Policy Secure gateways, giving an attacker control of the VPN appliance.
That access could lead to web shells, credential theft, internal reconnaissance, lateral movement and persistence. If your organization operated an affected gateway during the exploitation window, patching alone is not a sufficient investigation: you also need integrity checking, indicator hunting, credential rotation and a recovery decision that accounts for possible persistence.
As an Amazon Associate I earn from qualifying purchases.
The two vulnerabilities, in plain language
CVE-2023-46805: the authentication bypass
An authentication bypass allows a remote user to reach functions that should require a valid session. In this case, an attacker did not need a legitimate username, password or VPN session to access restricted parts of the gateway. The flaw effectively removed the first security door.
What’s actually slowing this PC down?
Pick the symptom - the matching free tool is one click away.
CVE-2024-21887: command injection
Command injection occurs when an application accepts attacker-controlled input and passes it to the operating system or an administrative component as a command. Requests crafted to exploit CVE-2024-21887 could make the appliance execute commands chosen by the attacker. This was the second door: once the bypass exposed the relevant functionality, command injection supplied execution.
#1 Best Overall
Why chaining mattered
Either flaw was serious. Chained together, they produced unauthenticated remote code execution, meaning an internet-reachable gateway could be taken over without prior credentials. CISA described the pair as an authentication-bypass vulnerability and a command-injection vulnerability in supported 9.x and 22.x versions of Connect Secure and Policy Secure gateways, and reported active exploitation.
“Ivanti has released a security update to address an authentication bypass vulnerability (CVE-2023-46805) and a command injection vulnerability (CVE-2024-21887) in all supported versions (9.x and 22.x) of Connect Secure and Policy Secure gateways.”
How the exploit chain worked
- Reach the exposed gateway. The attacker targeted an internet-facing Ivanti Connect Secure or Policy Secure appliance. A VPN gateway is normally designed to accept unsolicited connections, so perimeter exposure is part of its purpose rather than an unusual configuration.
- Bypass authentication. The attacker used CVE-2023-46805 to access restricted functionality without valid credentials. This established an application-level foothold while avoiding the normal login process.
- Send a command-injection request. The attacker used CVE-2024-21887 to submit crafted input that the appliance processed as an operating-system command.
- Execute code remotely. The two steps together enabled arbitrary command execution from the network, with the privileges available to the affected appliance services.
- Install a web shell or other tooling. Investigators documented web-shell deployment, including GLASSTOKEN and GIFTEDVISITOR variants. A web shell gives an intruder a repeatable way to issue commands through ordinary web traffic after the original exploit is closed.
- Use the gateway as an intelligence and access point. Follow-on activity included credential access, reconnaissance, lateral movement and persistence. The VPN appliance can contain account material and network knowledge that are valuable beyond the device itself.
The important distinction is between initial access and continued access. Patching addresses the vulnerable entry point. It does not, by itself, prove that a web shell, stolen credential or other persistence mechanism was never installed.
Rank #2
- Available with the Cloud Labs which provide a hands-on, immersive mock IT infrastructure enabling students to test their skills with realistic security scenarios
- New Chapter on detailing network topologies
- The Table of Contents has been fully restructured to offer a more logical sequencing of subject matter
- Introduces the basics of network security—exploring the details of firewall security and how VPNs operate
- Increased coverage on device implantation and configuration
What happened and when
| Date | Event | Why it matters |
|---|---|---|
| Early December 2023 | Volexity observed exploitation by the actor it tracked as UTA0178. | Compromise activity began before public disclosure. |
| January 10, 2024 | Volexity publicly reported the two vulnerabilities; CISA issued an alert. | The chain and active exploitation became broadly known. |
| January 31, 2024 | Ivanti listed patch releases for the four critical CVEs in the January sequence. | Remediation moved from emergency mitigation to branch-specific updates. |
| March 1, 2024 | A joint government advisory consolidated exploitation, detection and response guidance. | Defenders received expanded hunting and recovery recommendations. |
The affected product families were Ivanti Connect Secure and Ivanti Policy Secure. Advisories covered 9.x and 22.x branches. Availability of a fix depended on the appliance branch and the vendor’s current release guidance; use the update or mitigation instructions for the exact version installed rather than assuming that a package for one branch applies to another.
The separate CVE-2024-21893 issue
CVE-2024-21893 was a server-side request-forgery (SSRF) vulnerability in the SAML component. SSRF lets a server make requests to resources that an external user cannot normally reach. In the Ivanti case, the issue could expose restricted resources without authentication and therefore expanded the attack surface considered in later remediation guidance.
It was separate from the CVE-2023-46805 and CVE-2024-21887 pair. Treating it as a third step in the original two-flaw chain obscures the distinction: the first pair supplied the documented path to unauthenticated command execution, while CVE-2024-21893 created an additional unauthenticated route to protected resources.
Rank #3
How to determine whether an appliance was compromised
No single check can establish that a gateway is clean. Use the vendor’s latest external Integrity Checker Tool (ICT), then combine its result with independent log and network hunting. A clean result lowers concern about the files the tool can inspect; it does not prove that credentials were unused or that downstream systems were untouched.
1. Establish the exposure window
- Identify every Connect Secure and Policy Secure appliance, including standby, test and disaster-recovery units.
- Record product branch, software version, public addresses and the dates each unit was internet reachable.
- Preserve logs and configuration backups before changing systems, subject to your incident-response procedures.
2. Run the latest external ICT
Run Ivanti’s most recent external Integrity Checker Tool against each appliance, following the version-specific instructions. Review the complete output for modified, unexpected or missing files rather than treating a successful tool run as a blanket clearance.
3. Hunt for web shells and indicators
Use the indicators of compromise and detection methods in the CISA, joint government and Volexity reports. Look for unexplained web-accessible files, unusual administrative requests, processes or outbound connections, and activity that began during or shortly after the exploitation period. Correlate appliance telemetry with firewall, identity-provider, endpoint and cloud logs; a gateway may show only the first part of the intrusion.
Rank #4
- Used Book in Good Condition
4. Investigate account use outside the appliance
Review authentication events for administrator, service and user accounts associated with the gateway. Compare VPN logins, privileged actions, directory queries and access to internal applications with known user activity. Search for new accounts, changed authentication factors, unusual token use and connections from the appliance or its management network.
5. Preserve evidence before rebuilding
If indicators are present, isolate the appliance in a way that preserves evidence and involve your incident-response team. Capture relevant logs, network flows and volatile data when your procedures support it. Rebuilding first can remove the artifacts needed to determine scope and root cause.
What to do after the zero-day
- Apply the current Ivanti patch or mitigation. Follow the vendor guidance for your exact 9.x or 22.x branch. Emergency mitigations reduce exposure while an update is being staged; they are not a substitute for the supported patch when one is available.
- Limit exposure during remediation. Restrict management access, remove unnecessary internet paths and monitor the gateway and adjacent systems. Do not assume that a device is safe merely because it is behind another network control if remote users or partners can still reach it.
- Run the external ICT and perform independent hunting. Execute the latest tool, retain its output and check the results against the government and Volexity indicators.
- Rotate credentials stored on or passing through the gateway. Treat local administrator, directory, service, API, certificate, VPN and SAML-related secrets as potentially exposed. Rotate them from a trusted system, sequence changes to avoid outages, and invalidate sessions or tokens where your identity platform allows it.
- Examine downstream systems. Search directory controllers, jump hosts, management servers, file stores and cloud services for use of the affected credentials. The compromise impact can extend beyond the VPN appliance even if no second host shows malware.
- Choose recovery based on evidence. If compromise or persistence is indicated, follow the latest Ivanti and government recovery guidance. A factory reset by itself is not a sufficient answer when an intruder may have retained access or when credentials have been stolen.
- Document decisions and monitor after recovery. Keep patch records, ICT output, hunting queries, credential-rotation times and affected account lists. Increase monitoring for renewed access after the appliance returns to service.
Mitigation, patching, reset or rebuild: choosing a response
These actions solve different problems. The right sequence depends on whether you are reducing immediate exposure, establishing confidence about compromise, or restoring a trustworthy device.
Best Value
- Book
- Jones & Bartlett Learning
- CIST
- Information Security
- Network Security
| Option | Primary benefit | What it cannot establish or fix | Operational consideration |
|---|---|---|---|
| Emergency mitigation | Fastest reduction of exposure while an update is prepared. | Does not prove that exploitation did not occur or remove stolen credentials. | Apply the exact branch guidance and continue toward patching. |
| Vendor patch | Closes the known vulnerable code path. | Does not remove a web shell, persistence or attacker access established earlier. | Requires a maintenance window and version-specific planning. |
| External ICT plus independent hunting | Highest confidence available from the documented checks for altered files and known activity. | No tool can prove that every downstream action was absent. | Preserve output and correlate with enterprise logs. |
| Factory reset | Can return the appliance to a clean software state when performed under approved recovery procedures. | By itself, it does not address compromised credentials or explain what happened. | May cause downtime and can destroy evidence if done before collection. |
| Full rebuild or replacement | Strongest trust-restoration option when persistence or compromise is confirmed. | Does not undo activity already performed elsewhere in the network. | Requires configuration restoration, validation and coordinated credential changes. |
The government guidance treats credential compromise and persistence as separate decisions. That is why a patched appliance can still require credential rotation and why a reset can be inadequate without investigation.
Common mistakes that prolong the incident
- Waiting for a public exploit before acting. Volexity observed exploitation in early December 2023, before the January 10 public reporting.
- Stopping after installation of a patch. A patch blocks the known vulnerability; it does not answer whether an attacker used it earlier.
- Checking only the primary appliance. Include clusters, standbys, lab units and disaster-recovery systems that shared credentials or network paths.
- Rotating only VPN user passwords. Service accounts, administrators, API keys, certificates and SAML or directory secrets can be more consequential.
- Trusting a factory reset as the entire response. Resetting without hunting, evidence collection and credential changes can leave the organization exposed to a stolen-secret or downstream compromise.
- Looking only for malware on the gateway. Use identity, endpoint, firewall and cloud records to find lateral movement that may not leave a durable file on the appliance.
What the incident means for VPN defenders
A remote-access gateway deserves the same incident-response discipline as a high-value identity system. It terminates trusted connections, handles authentication material and sits at a boundary where a small appliance compromise can reveal a large internal environment. For future zero-days, maintain an inventory of internet-facing appliances, an out-of-band management path, tested emergency-change procedures, centralized logging and a credential-rotation runbook that does not depend on the potentially compromised device.
The practical lesson from this chain is to separate three questions: Can the attacker still enter? Patch or mitigate. Did the attacker enter? Use the ICT, indicators and independent hunting. What could the attacker have taken or changed? Rotate secrets and investigate downstream systems. Answering only the first question leaves the other two unresolved.
Crashes, No Sound, or Screen Glitches?
Random freezes, missing sound and display glitches usually trace back to one bad driver. Find and replace yours safely.Free scan · under a minutePC Slower Than It Used to Be?
A free scan shows the junk files, broken settings and background clutter dragging Windows down - then fixes them in one click.Free scan · Windows 10 & 11Quick Recap
Product prices and availability are accurate as of the date/time indicated and are subject to change. Any price and availability information displayed on Amazon at the time of purchase will apply.
