How Hackers Hack Corporate VPNs — and How to Protect Yourself
How attackers compromise corporate VPN access and what defenders should monitor.
🛡️
Defender's Guide
This is a defender-focused resource covering attack patterns at a conceptual level so you can recognise threats and protect yourself or your organisation. The page does not include step-by-step exploitation procedures. If you suspect you are currently being targeted or have been compromised, scroll to the recovery section below.
What attackers want from Corporate VPNs
Corporate VPN appliances have been among the most consistently exploited initial-access vectors in recent years. Public CISA advisories, Mandiant M-Trends reports, and incident-response retrospectives all point to the same pattern: perimeter VPN concentrators — particularly from Ivanti (formerly Pulse Secure), Fortinet, Citrix, SonicWall, Cisco ASA, and Palo Alto — have been repeatedly exploited via pre-authentication vulnerabilities to establish internal network access at major organisations.
Unlike consumer security guides, this page is written for the audience that actually defends these systems: security engineers, blue teams, network architects, and CISOs. The threat model is specific and well-documented: nation-state actors and ransomware affiliates treat corporate VPN appliances as high-priority targets because a single successful exploitation typically grants network-interior access bypassing perimeter controls, often with service-account-level credentials baked into the appliance configuration.
The defensive priorities for VPN appliances are different from general application security — patching speed is critical (N-day exploitation windows are often measured in days, not weeks), visibility into appliance behaviour is harder than for servers you control directly, and compromise scenarios require specific incident-response procedures because the appliance itself is in the trust path for network authentication.
How attackers actually do it
Conceptual attack categories, not exploitation procedures. Understanding these patterns is what lets you recognise and defend against them.
Pre-authentication vulnerabilities in VPN appliances
The dominant pattern. Publicly disclosed CVEs in Ivanti Connect Secure, Fortinet SSL VPN, Citrix NetScaler/Gateway, and others have been exploited at scale — frequently within days of disclosure, sometimes before patches are available (zero-day usage by nation-state actors). These vulnerabilities bypass authentication entirely, giving attackers shell or configuration access to the appliance.
Credential theft via VPN login portal phishing
Attackers clone VPN login portals and direct users via phishing. Victims enter corporate credentials and MFA codes, attacker uses in real-time to authenticate to the real VPN. Credential harvesting at scale across affected organisations. Defence: phishing-resistant MFA (FIDO2 hardware keys, passkeys) rather than TOTP codes that can be relayed.
Post-authentication exploitation via compromised valid accounts
Attackers with valid credentials (from password stuffing, phishing, info-stealer malware) authenticate legitimately then exploit weaker protections on the interior. Common pattern: contractor account with broad access, or former employee account not deprovisioned. Not a VPN vulnerability per se, but VPN is the channel through which valid-but-unauthorised access is established.
VPN client-side exploitation
Some VPN clients have had their own vulnerabilities — privilege escalation on endpoints, credential extraction from local storage, exploitation via crafted server responses. Less common than appliance-side issues but present in the threat landscape.
Session token theft and persistence
After initial compromise, attackers frequently establish persistence via stolen session tokens, scheduled tasks, modified appliance configurations, or planted backdoors in appliance firmware. The Ivanti compromises of 2024 specifically included evidence of firmware-level persistence surviving factory resets in some cases.
Lateral movement leveraging VPN-granted network access
Once attackers are through the VPN, they operate from inside the network perimeter. They enumerate Active Directory, identify valuable systems, escalate privileges, move laterally. The VPN exploitation is the initial access; the subsequent damage comes from interior network activity that is often under-monitored because "they are inside the perimeter so they must be legitimate."
Supply chain compromise via VPN vendor
Rarer but documented: the VPN vendor itself is compromised, resulting in backdoored firmware or stolen signing keys distributed to customers. Particularly concerning because customers have limited defensive options against this scenario beyond vendor-diversity and behavioural monitoring.
How to recognise compromise
Signs that your corporate vpns may have been compromised:
Anomalous authentication patterns on VPN logs
Logins from unusual geographic locations or time zones, logins from unexpected source IPs for known users, authentication bursts suggesting credential stuffing, successful authentications for accounts that should be disabled. SIEM correlation across VPN and identity provider logs surfaces these patterns.
Configuration changes on VPN appliance not correlated with change tickets
New users added, new routes configured, new authentication sources, firmware modifications. Any change not tied to authorised change management is suspicious. Many VPN appliances have inadequate audit logging; supplement with external configuration monitoring where possible.
Unusual network traffic originating from VPN appliance itself
The appliance making outbound connections to unexpected destinations, DNS queries outside normal patterns, traffic to known threat infrastructure. NetFlow/sFlow monitoring of appliance interfaces captures this.
CVE disclosures affecting your deployed VPN products
Not strictly an indicator of compromise, but a signal that urgent investigation is warranted. Organisations using affected products should assume compromise possibility during the window between disclosure and patching, and conduct targeted threat hunting for indicators.
Vendor-issued indicators of compromise or threat advisories
Ivanti, Fortinet, Cisco, Palo Alto issue IOCs and detection guidance when their products are actively exploited. Threat intelligence feeds aggregate these. Integrate with SIEM for automated matching; manually review for higher-confidence hunting.
Unusual user behaviour on the network interior after authentication
Authenticated user performing actions outside their normal pattern — accessing systems they do not normally access, enumerating Active Directory, running administrative commands, unusual data access volumes. May indicate their credentials are being used by an attacker post-VPN-authentication.
What actually protects you
Concrete actions ranked by impact. Items marked critical are the highest-leverage protections; do those first.
Aggressive patching cadence for VPN appliances
VPN appliances should be patched on the shortest timeline of any perimeter system — 48-72 hours from patch availability for critical vulnerabilities, with mitigations applied immediately if patches are not yet available. Most successful exploitation targets known CVEs patched weeks or months earlier. Establish explicit SLAs and executive accountability; track compliance.
Phishing-resistant MFA (FIDO2/WebAuthn, not TOTP)
TOTP and push-notification MFA can be relayed by real-time phishing proxies. FIDO2 hardware security keys or platform passkeys are phishing-resistant because they cryptographically bind to the legitimate origin. Mandate for VPN access; especially critical for privileged users, contractors, and users accessing sensitive data through VPN.
Zero Trust Network Architecture to replace traditional VPN
Traditional VPN model ("authenticated user = trusted user inside perimeter") is fundamentally the vulnerability. Zero Trust / SASE architectures (Cloudflare Access, Zscaler Private Access, Google BeyondCorp model, Tailscale, Netskope) replace monolithic VPN with per-application identity-aware access. Reduces blast radius of compromise; limits lateral movement after initial access. Multi-year migration for many organisations but strategic direction worth committing to.
Segment the VPN-accessed network interior
Even with traditional VPN, limit what successful VPN authentication grants. Network segmentation so VPN users can reach only what they specifically need. Jump hosts / bastion hosts for administrative access rather than direct VPN-to-production access. Micro-segmentation where feasible.
Comprehensive logging from VPN appliance to SIEM
Forward all authentication logs, configuration changes, and where available packet-level metadata to SIEM. Correlate with identity provider logs, endpoint logs, and network logs. Detection rules for known attack patterns (credential stuffing, impossible travel, unusual config changes, IOCs from threat feeds).
Configuration baseline and drift detection
Document expected VPN configuration; monitor for drift. Any change from baseline triggers review. Many VPN compromises involve attacker-added configuration that persists — detection of unauthorised configuration changes is a high-signal indicator.
Network access only from trusted source IPs where feasible
For user populations with predictable geographic distribution, restrict VPN access to IPs from expected countries or ASN ranges. Reduces attack surface; does not eliminate (attackers use residential proxies) but raises cost. Not always operationally feasible with mobile workforce.
Session timeouts and re-authentication for sensitive actions
Short VPN session timeouts with re-authentication required. Step-up authentication for access to sensitive systems. Reduces attack window when credentials are compromised.
Regular access audits and automated deprovisioning
VPN access tied to identity provider with automatic deprovisioning when users leave or change roles. Periodic audit of VPN-access-eligible users. Contractor access reviewed monthly minimum. Many incidents involve forgotten access from former employees or contractors.
Threat hunting specifically for VPN compromise indicators
Proactive hunting rather than waiting for alerts. Hunt for: authentication from residential proxy / VPN IPs used by attackers, authentication to VPN followed by rapid internal enumeration, VPN appliance making unusual outbound connections, configuration changes outside change windows. Dedicated threat hunting capacity pays off given the frequency of VPN targeting.
Frequently Asked Questions
Structural factors: they are internet-exposed by design, they process pre-authentication requests (so vulnerabilities in request handling bypass access controls), they often run proprietary code with less security research scrutiny than mainstream operating systems, patching cadence varies wildly across customers, and successful exploitation grants network-interior access bypassing perimeter controls. The combination makes them disproportionately valuable targets. Threat actors — both nation-state and ransomware-affiliated — have invested heavily in VPN-appliance research as a result.
Different threat profiles. Commercial appliances (Ivanti, Fortinet, Citrix, etc.) have rich feature sets but centralised attack surface — a single vulnerability class affects all customers. WireGuard and similar open-source alternatives have smaller attack surface, auditable code, and different deployment models but less feature breadth. Neither is strictly better; the right choice depends on organisational requirements, capability, and threat model. Many Zero Trust solutions (Tailscale, Cloudflare Access) use WireGuard or similar underneath.
Zero Trust replaces the "network perimeter = trust boundary" model with per-request identity-aware access decisions. Every access request is evaluated based on user identity, device posture, and resource sensitivity — regardless of network location. Eliminates the "authenticated VPN user has broad trust" problem that has driven many recent incidents. Practical implementations: Cloudflare Access, Zscaler Private Access, Google BeyondCorp, Tailscale, Netskope. Multi-year migration for most organisations; increasingly the strategic direction for enterprise remote access.
For critical pre-authentication vulnerabilities: 48-72 hours from patch availability for practical risk management. For vendor-provided workarounds when patches lag: same day. This is aggressive compared to general patch SLAs, but the observed exploitation windows support the pace. Organisations with slower cadence are routinely compromised during the gap. Executive-level commitment to the SLA and explicit accountability for missed windows are necessary; "we patch on our normal quarterly cadence" is insufficient for this asset class.
You should be actively managing the risk, not necessarily worried in the crisis sense. Specific actions: subscribe to vendor security advisories and automate alert escalation, maintain aggressive patching capability (see above), phishing-resistant MFA mandatory, forward all logs to SIEM with active monitoring, threat hunting for known IOCs from recent campaigns, defined incident response procedures specific to this asset class. If your controls are inadequate, the right response is investment rather than avoidance — these products are widely deployed for legitimate reasons and appropriate controls make them defensible.
MFA methods that cannot be relayed by real-time phishing proxies. TOTP codes and push-notification approvals CAN be relayed — attacker proxies your login to the real VPN while capturing your credentials and MFA response. FIDO2 hardware security keys (YubiKey, etc.) and platform passkeys (Windows Hello, Touch ID-backed keys) are phishing-resistant because they cryptographically bind to the origin domain. For VPN access specifically, this matters because real-time phishing of VPN credentials is a documented and active attack pattern.
Geographic access restrictions are a defence-in-depth layer with real but limited value. Restricting to countries where you have legitimate user presence raises attacker cost modestly (they use residential proxies or VPN providers in allowed countries). Does not stop determined attackers but does reduce opportunistic credential stuffing. Operationally annoying for travelling employees; document exception processes. Not a primary defence but worth considering as supplementary control.
Multiple signal sources combined: (1) authentication anomalies — impossible travel, unusual source IPs, burst patterns, (2) configuration drift detection on appliance, (3) IOC matching against threat intelligence feeds, (4) unusual appliance behaviour — outbound connections, DNS queries, (5) post-authentication interior activity anomalies — unusual enumeration, lateral movement patterns, (6) vendor advisories matching your deployed versions. No single signal is sufficient; correlation across sources produces defensible detection. Requires mature SIEM and threat hunting capability.
Depends on architecture — specifically what VPN access grants. Traditional model with broad network access: significant exposure including credential theft for every authenticated user, lateral movement opportunity, access to anything reachable from the VPN's network position. Segmented model with least-privilege access: more limited exposure scoped to what the VPN provides access to. Zero Trust model: minimal exposure — compromise of one access point does not grant broad trust. This is why architectural direction matters as much as individual appliance security.
Yes, with proportional investment. Ransomware affiliates specifically target small and mid-sized organisations via VPN exploitation — the attack economics work because automated scanning and exploitation at scale is cheap. Smaller organisations often have weaker controls, making them easier targets for the same automated campaigns. Appropriate baseline for small organisations: modern VPN product kept patched promptly, MFA (hardware keys where budget allows, TOTP as minimum), log forwarding to a managed detection service or cloud SIEM, documented incident response plan. Does not require enterprise security team; does require explicit attention.