Skip to main content

Cybersecurity · How-To

Ivanti VPN Exploitation: What Businesses Should Check

Attackers reportedly chained flaws in Ivanti Connect Secure. Businesses should check exposure, apply vendor guidance and review remote access.

By Abrimatt Research DeskTechnology research4 min read

Researched and drafted with AI assistance, then reviewed and published by the Abrimatt team.

Executive summary & key takeaways

  • SecurityWeek reported that attackers exploited a flaw in Ivanti Connect Secure VPN appliances.
  • Ivanti patched two vulnerabilities, while a third reported flaw remained unpatched.
  • A fully patched appliance was reportedly compromised through a chain of vulnerabilities.
  • Check appliance versions, vendor guidance, credentials and remote-access controls.

SecurityWeek reported that attackers chained vulnerabilities in Ivanti Connect Secure (ICS) VPN appliances to gain root-level access, including on an appliance described as fully patched. Ivanti said it was aware of exploitation affecting a limited number of customers. For a business using ICS, the practical issue is not just whether a patch has been installed. It is whether the appliance is affected, whether vendor guidance has been followed and whether access through the VPN could expose other systems.

Establish whether your business is exposed

Start by confirming whether your organisation uses Ivanti Connect Secure and identifying the versions in operation. SecurityWeek reported that Ivanti released patches for two vulnerabilities in ICS versions 22.8R2.5, 25.1.1.2, 25.1.3.0 and 25.1.3.1. Check Ivanti’s current guidance to establish which actions apply to your appliance and version. Do not assume that a system is safe simply because it is described internally as fully patched: the reported attack chain affected a fully patched appliance.

SecurityWeek said a third vulnerability, involving privilege escalation, remained unpatched at the time of its report. Ivanti planned to address it, but the report did not say that a fix had already been released. That makes it important to check the vendor’s latest instructions rather than relying on a past update or an assumption about the remaining flaw.

Treat a patch as one part of the response

According to SecurityWeek, the vulnerabilities included an authentication bypass and a remote-code-execution flaw. The reported activity also involved credential theft, network reconnaissance and log tampering. Volexity found that attackers searched Active Directory for LAPS passwords and BitLocker recovery keys, and tried to test credentials. These details matter because the concern may extend beyond the VPN appliance itself.

If the appliance may have been exposed, involve the people responsible for your IT and security. They can review available appliance and authentication logs, check whether vendor guidance calls for further action, and consider whether credentials stored on or used through the appliance need attention. SecurityWeek reported that attackers parsed authentication logs to identify valid usernames, so reviewing access records is a relevant part of understanding what happened. Do not treat the absence of a visible backdoor as proof that no information or credentials were accessed: Volexity reported finding no backdoor or web shell, but also described other activity.

Review the path into your network

The incident is a prompt to ask what the VPN can reach and which people or systems depend on it. Review who is permitted to connect, what access they receive after connecting, and how credentials are protected. Check whether administrators can identify unusual access and respond if an account or appliance is suspected of compromise.

For a growing business, these are operational questions as well as technical ones. Remote access may support staff and business processes, but it also creates a route into internal systems. Make clear who can approve changes to access, who checks security alerts and who coordinates a response if the appliance is affected. If your team cannot answer those questions, document the gaps and assign an owner to resolve them.

What to do next

  • Confirm whether Ivanti Connect Secure is in use and record the appliance versions.
  • Check Ivanti’s latest security guidance and apply the actions relevant to your environment.
  • Ask your IT or security team to review access records and assess whether credentials or connected systems may be affected.
  • Revisit remote-access permissions, monitoring and incident-response responsibilities.

SecurityWeek reported that Volexity detected and disrupted the activity before the attackers’ ultimate goals became clear. That does not establish what happened in every organisation. Use the report as a reason to verify your own exposure and decisions, not as evidence that your business has been attacked—or that applying a patch alone settles the question.

Sources

  1. Ivanti Zero-Day Chain Gave Attackers Root Access to Fully Patched VPN (opens in a new tab) · SecurityWeek

Where Abrimatt can help

Topics:IvantiVPN securityVulnerability managementRemote access