Secure Remote Access: VPN Hardening and Zero Trust Alternatives

Virtual Private Networks (VPNs) remain the dominant remote access mechanism for enterprise environments, but the security posture of most deployed VPN infrastructure is inadequate. SSL VPN appliances — specifically internet-facing, always-on, handling credential authentication — are among the highest-value targets in enterprise networks. The exploitation record from 2022-2025 is unambiguous: VPN appliances from every major vendor have been mass-exploited, with threat actors achieving unauthenticated remote code execution before patches were available to most organizations.

The VPN Exploitation Crisis

The pattern is consistent: a critical vulnerability is disclosed in an SSL VPN product, proof-of-concept exploit code appears within 24-72 hours, nation-state and ransomware actors begin mass exploitation within days, and the majority of affected organizations have not patched within the exploitation window. Consider the timeline:

• Ivanti Connect Secure CVE-2024-21887 + CVE-2023-46805: A command injection vulnerability (CVE-2024-21887) chained with an authentication bypass (CVE-2023-46805) in Ivanti Connect Secure (formerly Pulse Secure). Active exploitation began in December 2023 before the January 2024 public disclosure. CISA estimated thousands of devices were compromised globally. A subsequent wave of CVEs (CVE-2024-21888, CVE-2024-21893) hit before organizations had recovered from the first. Mandiant attributed initial exploitation to UNC5221, a China-nexus threat actor.
• Fortinet CVE-2022-40684: An authentication bypass in the FortiOS administrative interface allowing a threat actor to perform operations on the administrative interface via specially crafted HTTP requests. CVSS 9.8. Exploitation was observed in the wild within days of disclosure. Within days of the October 2022 advisory, the Shadowserver Foundation identified more than 17,000 internet-exposed Fortinet devices as likely vulnerable (Shadowserver Vulnerable Fortinet Special Report, 14 Oct 2022).
• Cisco ASA CVE-2023-20269: A zero-day vulnerability in Cisco ASA and FTD SSL VPN allowing unauthenticated remote attackers to conduct brute-force attacks against existing local accounts. Akira and LockBit ransomware operators leveraged this for initial access before Cisco published a patch.
• Palo Alto Networks GlobalProtect CVE-2024-3400: A command injection vulnerability in PAN-OS GlobalProtect feature allowing unauthenticated remote code execution as root. CVSS 10.0. Volexity and Palo Alto Unit 42 observed exploitation by UTA0218, a suspected state-sponsored threat actor, before the patch was available.

The common thread: SSL VPN appliances are internet-facing, they process pre-authentication traffic from untrusted sources, and they grant successful attackers broad network access. This makes them the ideal initial access vector — which is exactly how threat actors treat them.

Why SSL VPNs Are High-Value Targets

From an attacker's perspective, compromising a VPN appliance is superior to most other initial access methods:

• Internet-facing by design: The appliance must be publicly accessible for legitimate users. Restricting access by source IP defeats the purpose for organizations with distributed workforces.
• Broad network access: A successful VPN authentication grants access to internal network segments. A compromised VPN appliance gives the attacker the same access — plus the ability to intercept credentials of every user who authenticates.
• Credential harvesting: VPN logs contain authentication events. A compromised appliance that exfiltrates logs passively collects valid usernames and passwords for later use or sale.
• Delayed detection: VPN appliances often have limited EDR visibility. Security teams focus endpoint detection on workstations and servers — network appliances running proprietary OS images frequently have no behavioral monitoring.

VPN Hardening: The Practitioner Checklist

If your organization depends on SSL VPN infrastructure and replacement with ZTNA is not immediately feasible, these controls reduce risk materially:

• Mandatory MFA for all VPN authentication: Password-only VPN authentication is not acceptable in 2025. TOTP hardware tokens or push-based MFA (Duo Security, Microsoft Authenticator) must be enforced at the policy level — not offered as optional.
• Client certificate + password (mutual TLS): Require both a valid client certificate issued by your internal CA and a password/MFA. This eliminates credential stuffing attacks because the attacker would also need a valid device certificate.
• Disable split tunneling: Split tunneling allows users to route internet traffic directly while routing internal traffic through the VPN. This means a user on a compromised home network can introduce malware that accesses internal resources directly through the VPN tunnel. Force all traffic through the VPN and inspect it.
• Restrict allowed source IP ranges where feasible: For roles where the user population is known (e.g., a remote development team in a fixed location), allowlist source IP ranges. This does not help for broadly distributed workforces but significantly reduces exposure for specific use cases.
• Network Access Control (NAC) integration: Verify device health posture before granting VPN access. Systems with outdated AV definitions, disabled disk encryption, or policy violations should receive quarantine network access rather than full internal access.
• Aggressive patching with emergency procedures: Critical VPN CVEs require emergency patching — not the next scheduled maintenance window. Establish an emergency patch procedure for CVSSv3 ≥9.0 vulnerabilities in internet-facing appliances with a 24-48 hour SLA.
• Monitor authentication logs for credential stuffing: Alert on repeated failed authentication attempts per source IP and per username. Baseline authentication velocity and alert on deviations. Brute force and credential stuffing precede most VPN compromises.
• Disable legacy authentication protocols: IKEv1, SSLv3, TLS 1.0, and TLS 1.1 should be disabled. Weak cipher suites (RC4, 3DES, NULL) must be removed from the supported cipher list.

Transition Path to Zero Trust Network Access

ZTNA (Zero Trust Network Access) replaces the VPN model by granting access to specific applications rather than network segments. The user authenticates to a cloud-hosted broker, which evaluates identity, device posture, and context before proxying access to the specific application requested. The underlying network is never exposed.

Leading ZTNA platforms include Zscaler Private Access (ZPA), Cloudflare Access, Palo Alto Prisma Access, and Microsoft Entra Private Access. The architectural shift removes the internet-facing VPN appliance as an attack surface entirely — there is no network endpoint for attackers to target.

The migration path is incremental: identify high-priority applications for ZTNA migration (typically those with the broadest user population or most sensitive data), pilot ZTNA alongside existing VPN, migrate application by application, and eventually decommission the VPN. For organizations with legacy applications that cannot be fronted by ZTNA brokers, Fortress MSSP's managed network infrastructure services can architect hybrid approaches that reduce risk during transition.

The Fortress MSSP network penetration testing team can assess your VPN deployment for the exploitable misconfigurations described above. Contact us to schedule an assessment.