Securing Cisco AnyConnect and Legacy VPNs Against Infostealer-Driven Breaches

Infostealer malware has changed the threat model for remote access. Attackers no longer need to brute-force passwords or burn expensive zero-days when they can buy fresh credentials, cookies, and session tokens on underground markets for a few dollars. For teams still running AnyConnect and other legacy VPN migration patterns, this matters because the VPN is often the easiest path from a stolen laptop profile to a privileged internal network. The hard truth is that traditional VPN design assumed trust after authentication, while infostealers thrive on stealing that trust after login.

This guide is a practical hardening playbook for UK IT leaders, security engineers, and MSPs that need to keep legacy remote access alive while shrinking blast radius. We will cover posture checks, session hijack detection, token revocation, network segmentation, Cisco patch hygiene, and phased plans to remove the old “VPN-as-flat-network” model. If you are comparing your current setup against modern alternatives, it also helps to review AnyConnect vs ZTNA and the broader VPN hardening guide before making migration decisions.

Pro Tip: In an infostealer incident, the important question is not “Was MFA enabled?” It is “What did the attacker already capture from the endpoint, browser, or SSO session before MFA ever mattered?”

1. Why Infostealers Are So Dangerous for VPN Environments

Infostealers are purpose-built to collect browser passwords, session cookies, device fingerprints, password manager data, and sometimes cloud auth artifacts. That means a user can be fully patched, fully compliant on paper, and still become a valid entry point if their endpoint was already compromised. Huntress’ recent reporting highlighted how stolen credentials and outdated Cisco AnyConnect access can be combined into a very real-world breach path, with early reconnaissance and lateral movement detected only after the attacker was already inside.

Session hijack beats password theft

Traditional credential theft requires the attacker to know or guess a password and then defeat MFA or exploit a weak reset process. Infostealers often skip that entire chain by stealing authenticated browser sessions, VPN cookies, or SSO tokens. Once those tokens are replayed, the attacker may appear indistinguishable from a legitimate user unless you are correlating device posture, IP reputation, geo-velocity, and login history.

This is why many teams see “successful MFA” in logs and still experience intrusion. A stolen session can carry the trust of an already-approved authentication flow, especially if the authentication system does not aggressively bind sessions to device context. If you want the operational side of that shift, our session revocation playbook explains the revocation steps many teams forget during incident response.

Why legacy VPNs are especially exposed

Legacy VPN stacks were built to extend the internal network, not to continuously verify every request. Once the tunnel is up, the user often inherits broad access to file shares, admin consoles, and internal apps that were never designed for hostile users on the inside. That architecture becomes dangerous when the initial access vector is a stealer-loaded endpoint rather than a clean corporate laptop.

In practice, the attacker’s job becomes easier the flatter the network is. If a stolen AnyConnect account lands in a “trusted internal” VLAN with permissive routing, SMB visibility, and weak service account hygiene, the attacker can move laterally with very little friction. For a broader view of where these architectures go wrong, see flat network risks and the zero trust remote access decision framework.

The economics favor attackers

Infostealers are cheap to deploy and cheap to buy. That shifts the attacker economy from “high-skill exploit” to “high-volume identity theft,” which is bad news for any business that relies on legacy remote access without strong telemetry. The result is a flood of low-cost, high-success intrusion attempts where the attacker can test a stolen session, probe internal routes, and pivot before a human notices.

That economic reality is why remote-access hardening is not just a technology choice but a risk-management choice. UK teams also need to account for compliance and governance exposure when internal systems are reached using stolen identities, especially where personal data or regulated information is involved. For related governance work, see UK GDPR VPN compliance and remote access risk assessment.

2. Start With Endpoint and Identity Posture Checks

You cannot secure a VPN if the devices using it are already contaminated. The first control layer should be endpoint posture: OS version, patch status, EDR health, browser hardening, password manager hygiene, and evidence of active stealer infection. In a practical rollout, posture checks should gate access to the VPN, but also to high-risk internal applications once the user is connected.

What to check before tunnel establishment

For AnyConnect and comparable legacy VPNs, your connection policy should examine more than username and password. Require managed device status, disk encryption, current security agent health, recent patch recency, and proof the endpoint is not jailbroken, rooted, or otherwise non-compliant. If the client can posture-check certificates and EDR state before the tunnel fully opens, you can stop many risky sessions before they ever touch internal resources.

Posture checks are most effective when they are specific and enforceable. A vague “healthy device” flag is not enough; you need a control matrix with exact thresholds, such as “Windows 11 patch level within 14 days,” “macOS with approved EDR active,” and “no signs of browser cookie theft or suspicious persistence.” For teams formalising this work, endpoint compliance for VPN is a strong companion reference.

Identity hardening is not just MFA

MFA remains necessary, but it is no longer sufficient. Modern access control should combine MFA with conditional access, device binding, and short-lived credentials where possible. If you rely on long-lived sessions or persistent cookies, infostealers can turn one successful login into a prolonged breach window even after passwords are reset.

That is why identity hygiene and revocation workflows matter. When a suspicious login occurs, your team should know how to invalidate refresh tokens, revoke browser sessions, expire VPN sessions, and force re-authentication across connected SaaS platforms. A useful starting point is MFA for remote access, but the key is to treat MFA as one control in a chain, not the chain itself.

Browser and password manager exposure

Infostealers love browsers because they concentrate passwords, cookies, and SSO artifacts in one place. Teams often overlook that the browser itself may be the real remote-access client, especially when users authenticate via corporate SSO before entering VPN portals or web-based admin consoles. If a stealer exfiltrates those assets, the attacker may never need the VPN password at all.

To reduce this risk, enforce browser isolation on admin workstations where possible, disable password storage in unmanaged browsers, and require enterprise password managers with device-based unlock controls. If you are reviewing tool choices for this layer, our password manager policy guide explains how to prevent credential sprawl without slowing down users.

3. Patch Cisco AnyConnect and the Supporting Stack Aggressively

Legacy VPN deployments often fail not because the core product is inherently broken, but because the environment around it is stale. Cisco regularly publishes fixes for critical and high-severity issues, and those patches matter because authentication bypass, privilege escalation, and remote code execution in the surrounding stack can become the next foothold after an infostealer-led login. Your patch program must cover the VPN headend, ASA/FTD or equivalent appliances, authentication integrations, and the management plane.

Patch the VPN appliance, not just the client

Many organisations update the AnyConnect client on laptops but forget the concentrator, firewall, or identity proxy that terminates the session. That is a dangerous gap because a compromised endpoint only needs one vulnerable appliance to turn a stolen login into full control. Build a patch inventory that includes software version, model, support status, and exposure history for every remote access component.

In the UK, where many teams operate hybrid estates and legacy perimeter devices, this inventory often reveals a more urgent issue: not all VPN boxes are still under active support. If a device cannot be patched fast enough, it should be isolated, fronted by additional controls, or retired. For practical decision-making, see Cisco security advisories and VPN appliance lifecycle management.

Accelerate maintenance windows for security fixes

Security patches for remote access systems should not wait for quarterly maintenance cycles when active exploitation is plausible. Define an emergency patch path with a short approval chain, rollback plan, and validation checklist so that critical fixes can be deployed in hours, not weeks. A delayed patch on an internet-facing VPN can be the difference between a contained alert and a reportable breach.

To make this sustainable, pre-stage configuration backups and test patches in a representative lab. If you do not have a lab, create one from a spare appliance, an isolated VM, or a cloud replica of your authentication flow. For more structure around this, the emergency VPN patching guide is useful alongside your change advisory process.

Don’t ignore certificates and integrations

Expiring certificates, weak TLS profiles, outdated RADIUS, and brittle SSO integrations are common failure points in legacy remote access. These are also the kind of problems that cause admins to leave systems unchanged because the “VPN still works,” even though the security posture is deteriorating behind the scenes. Every supporting integration should be audited for weak cipher suites, stale keys, and poor logging.

Where possible, standardise on modern SSO and certificate-based controls with central logging. If the VPN is still a critical business service, you need observability equivalent to a core production application. For deeper implementation advice, see VPN certificate management and SSO and MFA VPN integration.

4. Treat Session Tokens as High-Risk Assets

One of the biggest mistakes in infostealer response is focusing only on password resets. If cookies, refresh tokens, or active sessions remain valid, the attacker can continue accessing resources even after the password changes. In many modern environments, revocation must be explicit, not implied.

Know which tokens exist in your stack

Your identity provider, browser-based apps, VPN concentrator, and device management platform all issue different session artifacts. Some expire naturally, some are refreshable, and some survive password changes unless they are manually revoked. Make a map of every token type in your environment and document exactly how it is invalidated.

This token map should be part of your incident response runbook. When a stealer is suspected, the IR team should know which admin portal to use, which API endpoint to call, and which conditional access policy to temporarily tighten. For a tactical walkthrough, see session token revocation and identity response runbook.

Shorten session lifetime and force re-authentication

Long-lived VPN sessions are convenient, but they are also a gift to attackers. Shorter session lifetimes reduce the dwell time of a stolen login, especially if you require step-up authentication when users access sensitive subnets or admin portals. The goal is not to punish normal users; it is to force trust revalidation at the moments when risk is highest.

A balanced model often uses a standard session window for routine work, then triggers re-authentication for privileged actions, unusual geography, or access to production systems. This is where modern policy engines outperform older “authenticate once, trust forever” designs. See step-up authentication and adaptive access policies for examples of how to reduce exposure without breaking operations.

Revocation must include SaaS and SSO

Infostealers rarely stop at the VPN. They also steal access to Microsoft 365, Google Workspace, CRM tools, documentation platforms, and admin consoles that may be reachable from the VPN session itself. If your response only disables the VPN account, the attacker may keep moving through already-authenticated SaaS sessions or cloud admin tokens.

For that reason, incident response should treat VPN compromise as an identity event across the whole stack. Tie your VPN playbook to M365, Google, and endpoint actions so that compromise in one place triggers lockout in all relevant systems. That workflow is covered in ITDR for VPN attacks and SaaS session revocation.

5. Remove “VPN-as-Flat-Network” Architecture

Legacy VPNs are dangerous when they place every authenticated user into the same broad internal network as servers, admin tools, and sensitive file shares. If an attacker lands on one endpoint, they can often discover the rest through SMB, LDAP, RDP, or internal web services. Segmentation is how you turn a single stolen session into a small, manageable incident instead of a company-wide crisis.

Segment by role, device trust, and application sensitivity

Do not route every VPN user to the same internal address space. Instead, segment access by function: finance gets finance systems, developers get dev tooling, contractors get tightly scoped project networks, and admins get isolated management planes. This can be done with VRFs, ACLs, firewall zones, jump hosts, or application gateways depending on your stack and appetite for change.

Role-based segmentation also makes your security team’s life easier because suspicious traffic becomes easier to spot. If a user in sales starts touching domain controllers or backup infrastructure, that anomaly should be immediately obvious. If you need a design reference, see role-based network access and segmentation design for VPN.

Put admins behind separate controls

Administrative access should never share the same trust zone as ordinary employee access. Admins should use separate accounts, separate workstations where feasible, and separate network paths to management planes. This not only contains infostealer risk but also improves auditability and makes privileged activity far easier to monitor.

A practical model is to require a hardened admin jump host with explicit logging, MFA, and restricted clipboard and file transfer controls. That way, even if an infostealer compromises a day-to-day user endpoint, it cannot automatically inherit elevated access to production systems. For more on this pattern, review privileged access segmentation and jump host best practices.

Use application access, not network access, whenever possible

The most effective way to break the flat-network model is to stop granting broad network reach in the first place. If a user only needs one internal app, publish that app through an application proxy, ZTNA broker, or per-app tunnel rather than exposing an entire subnet. This limits lateral movement, reduces scanning, and makes token theft much less useful to an attacker.

Many organisations cannot flip that switch overnight, but they can start with sensitive applications first. Critical internal systems, HR portals, and admin consoles are good candidates because they are high value and usually accessed by a small user set. For roadmap ideas, see per-app access model and ZTNA migration roadmap.

6. Build a Detection and Response Plan for Session Hijack

Once infostealer-driven compromise is a possibility, your detection strategy has to look for behaviour that follows valid authentication, not just failed logins. That includes impossible travel, unusual device fingerprints, rare subnet access, off-hours lateral movement, and administrative actions inconsistent with the user’s normal role. This is where VPN logs, endpoint telemetry, identity events, and SIEM correlation must work together.

Correlate endpoint, identity, and network events

An attacker using a stolen session may appear clean in one log source and suspicious in another. For example, the VPN could show a valid login while the endpoint agent flags browser credential dumping or the identity provider logs a token replay from a new device. Your SOC should be able to fuse these signals into a single incident narrative.

Do not rely on one console to tell the full story. Instead, centralise logs from the VPN headend, identity provider, EDR, DNS, and firewall into a platform that supports correlation and alert suppression. If you are building that capability, SIEM for remote access and ITDR for remote access are useful references.

Build specific indicators for hijacked sessions

A hijacked session often leaves subtle clues: new geographies, odd logon times, rapidly enumerated network shares, or access to resources the user has never touched before. Alerting on these patterns can surface attacks that would otherwise blend in with normal remote work. The signal improves even more when combined with device trust and known-good baselines.

Use case-based detections rather than generic “suspicious activity” rules. For example: a user authenticates from a UK office IP, then within minutes accesses a US cloud admin panel, or a low-privilege contractor account starts enumerating backup servers. For practical examples, see session hijack detection rules and anomaly detection for VPN.

Prepare the response workflow in advance

Your incident response team should not be improvising token revocation during a live breach. Document who can suspend VPN users, revoke SSO sessions, disable affected accounts, isolate endpoints, and notify stakeholders. A good runbook also tells the team when to preserve evidence, when to begin containment, and when to escalate to legal or data protection officers.

This is especially important in the UK because the operational response may intersect with UK GDPR obligations, supplier notifications, and potentially law enforcement involvement. For governance and process alignment, see incident response for VPN compromise and UK GDPR incident handling.

7. A Phased Migration Plan Away From Legacy VPN Dependence

Not every team can rip out AnyConnect or another legacy VPN next quarter, and pretending otherwise is a mistake. The right approach is phased migration: harden what you have, reduce flat-network exposure, then move the highest-risk use cases to per-app or zero-trust access. This lets you lower risk while preserving business continuity.

Phase 1: Inventory and risk rank

Start by mapping every VPN user group, subnet, auth method, and dependent application. Rank access by sensitivity and by how much of the internal network each group can see. This inventory often reveals easy wins, such as contractors who only need one application but currently get broad network access.

As you work through the inventory, identify obsolete clients, unsupported concentrators, and dormant accounts. Those are often the easiest breach paths to close quickly. For a structured starting point, use VPN access inventory template and dormant account review.

Phase 2: Contain and compartmentalise

Next, place guardrails around the most sensitive systems and reduce the number of users who can reach them through the legacy VPN. Introduce admin jump hosts, split tunnels where appropriate, stronger conditional access, and subnet-level segmentation. This does not solve everything, but it makes lateral movement much harder.

Use this phase to build stakeholder confidence. When teams see that operations continue without a full network blast radius, they become much more open to structural change. That is where the migration can move from theory to funded initiative. See VPN split tunnel risk and compartmentalise remote access.

Phase 3: Replace broad VPN use cases

Finally, migrate the biggest offenders: remote admin access, third-party access, and single-application workflows. These are the best candidates for ZTNA, reverse proxy access, or identity-aware application publishing because they do not actually require full network connectivity. Every migration here removes a chunk of legacy risk and reduces dependence on a monolithic tunnel.

It is also a good time to revisit procurement assumptions. If your future architecture requires fewer broad tunnels, then pricing, support, and lock-in criteria change too. Compare your options with remote access procurement checklist and vendor lock-in in VPN.

8. Operationalising the Controls: Policies, Metrics, and Ownership

Hardening only works if it becomes operational. That means clear ownership for patching, access review, incident response, and user lifecycle management. Without accountability, every security control eventually decays into “documented” but unenforced policy, which attackers love.

Define ownership across teams

VPN hardening sits at the intersection of network, identity, endpoint, and security operations. Someone must own the VPN appliance, someone must own identity policy, someone must own segmentation, and someone must own incident response. In smaller UK businesses, that may be one IT lead wearing several hats, but the ownership still needs to be explicit.

For leadership alignment, the idea is similar to IT ownership model and security operating model: clear responsibility prevents gaps that attackers exploit. If a control has no named owner, it will not survive the next busy quarter.

Track metrics that show real risk reduction

Useful metrics include percentage of VPN users on managed endpoints, average patch age for VPN components, number of privileged users on segmented paths, time to revoke a suspicious session, and percentage of non-admin users with access to production subnets. These metrics are more meaningful than raw login counts because they show whether the architecture is becoming harder to abuse. They also help justify budget for phased migration work.

Use your metrics to tell a narrative, not just fill a dashboard. Show how many potentially stolen sessions were invalidated, how much lateral reach was removed, and how many legacy access paths were retired. That story is what convinces executives that hardening is reducing business risk, not just adding technical complexity. For reporting ideas, see security metrics dashboard and VPN risk reporting.

Make the user experience part of the design

Security that constantly breaks remote work will be bypassed, shadow-IT’d, or quietly exempted. Design controls that are strict for privileged actions but low-friction for everyday access. For example, admins can accept a tighter workflow if they know it is consistent, fast, and clearly justified.

This balance is where thoughtful architecture wins. The objective is not to make the VPN miserable; it is to make stolen sessions useless while keeping employees productive. If you need a practical benchmark, compare your approach to secure remote work balance and user experience security controls.

9. A Practical 30-60-90 Day Action Plan

Teams often ask what to do first. The answer is to focus on the controls that reduce real attacker utility fastest: revoke stolen sessions, patch exposed systems, shrink network reach, and isolate high-value admin paths. That sequence gives you immediate improvement without waiting for a full platform replacement.

First 30 days

Inventory all remote-access entry points, identify your legacy VPN versions, and verify whether your Cisco components are fully patched and supported. Tighten MFA, shorten session lifetimes where possible, and make token revocation a documented incident-response task. Start alerting on suspicious new geographies, impossible travel, and endpoint signs of infostealer activity.

This is also the moment to remove obsolete accounts and disable any user who no longer needs VPN access. Even a small reduction in access surface can prevent a major incident. Use first 30 days VPN hardening as a tactical checklist.

Days 31-60

Introduce segmentation for the most sensitive subnets and move admins to separate access paths. Correlate VPN, identity, and EDR logs into one detection view, and test your revocation workflow with tabletop exercises. If the team cannot invalidate a suspicious session in minutes, the process needs redesign.

Use this period to remediate the most dangerous legacy assumptions: flat access, shared admin paths, and long-lived sessions. These fixes are often more important than “new features” because they directly neutralise infostealer abuse. A good companion resource is 60-day remote access hardening.

Days 61-90

Begin moving single-application and third-party use cases off the broad VPN and onto narrower access methods. Document the business case for retiring any unsupported concentrators or obsolete auth integrations. If the migration needs funding, present it as a risk-reduction and operational-simplicity project, not just a security upgrade.

By the end of 90 days, you should be able to demonstrate measurable improvement: shorter dwell time, fewer users with broad internal access, cleaner patch status, and better confidence in incident response. From there, the long-term path is gradual retirement of legacy VPN as a default access model. For that strategic step, review legacy VPN retirement plan.

10. Final Recommendations for UK Teams Still Running AnyConnect

If your organisation still depends on AnyConnect or another legacy VPN, the goal is not panic; it is controlled reduction of risk. Infostealers have made identity theft cheap and scalable, which means a perimeter-era access model now carries outsized downside. You can keep the VPN operational while making it materially harder for stolen credentials and tokens to translate into a breach.

The highest-value sequence is straightforward: enforce posture checks, harden identity, revoke sessions aggressively, segment the network, and remove broad “flat network” access wherever possible. Then use those improvements to justify phased migration toward per-app access and zero-trust patterns. If you want a broader strategic comparison, it is worth reading VPN vs ZTNA for SMBs and the Cisco AnyConnect hardening reference.

Pro Tip: The most effective legacy VPN security programs don’t try to make the old architecture perfect. They make it smaller, less trusted, better observed, and easier to replace.

No. MFA helps, but infostealers often steal already-authenticated sessions, cookies, or refresh tokens, which can bypass the need to re-enter MFA. That is why device posture, short session lifetimes, and explicit token revocation are essential.

2) What should we revoke first after suspected compromise?

Revoke active VPN sessions, identity provider refresh tokens, and browser-based SSO sessions as quickly as possible. Then isolate the endpoint and assess whether credentials, cookies, or admin tokens were exposed beyond the VPN stack.

3) How do we know if our VPN is acting like a flat network?

If most authenticated users can reach broad internal subnets, shared admin interfaces, or sensitive servers without additional checks, your VPN is functioning like a flat network. A simple test is to trace what a low-privilege user can access immediately after login.

4) What is the fastest hardening win for AnyConnect?

For most teams, the fastest win is aggressive patching plus session lifetime reduction plus better logging correlation. That combination immediately lowers the value of stolen sessions while you work on segmentation and migration.

5) Do we need to replace AnyConnect to be secure?

Not immediately. You can substantially reduce risk by hardening the current stack, segmenting access, and introducing per-app controls for high-risk use cases. That said, over time, legacy broad-access VPN should be phased down in favour of narrower access models.

6) How should UK teams think about compliance?

UK GDPR and internal governance obligations mean you need to show reasonable technical and organisational measures, not just a product purchase. Evidence of patching, access review, session revocation, and segmentation will help demonstrate that you took the threat seriously and acted proportionately.

Related Reading

• Zero Trust Remote Access - See how to reduce trust in the network and increase it in the identity and device.
• AnyConnect vs ZTNA - Compare legacy VPN access with modern per-app remote access.
• UK GDPR VPN Compliance - Understand the governance and evidence you need for remote access.
• VPN Appliance Lifecycle Management - Plan patching, support status, and retirement of exposed devices.
• Legacy VPN Retirement Plan - Build a phased roadmap away from broad-access tunnels.