Network Breach Response Plan: Edge Devices, Lateral Movement and When to Isolate

Most network breaches now start at the edge: a VPN, firewall or remote-access gateway with a flaw attackers are already exploiting. The response that works is: capture the device’s evidence before you patch or reboot it, treat every credential that touched it as stolen, hunt for lateral movement, and isolate in proportion to what you know. Patching closes the door; it does not remove anyone who already walked through. This guide is the network playbook in the master plan and playbooks structure; the incident response hub has the rest.

What counts as a network breach?

• Edge-device exploitation: VPN concentrators, firewalls, load balancers and remote-access gateways.
• Lateral movement from a first foothold to servers, admin workstations and domain controllers.
• Domain compromise: an attacker with domain admin rights or equivalent.
• Command-and-control (C2): regular beaconing from inside to unknown infrastructure.

Triggers that route here: a vendor advisory or an entry in CISA’s Known Exploited Vulnerabilities catalogue for a device you run, odd processes on an appliance, a new domain admin, or beaconing seen in network logs.

What should you do first when an edge device is exploited?

1. Declare under the master plan. An exploited edge device is a potential full-network incident until shown otherwise.
2. Collect before you change anything. Export the device’s logs, configuration and, where the vendor supports it, a system snapshot or core dump. Many appliances keep little on disk and lose volatile evidence on reboot.
3. Run the vendor’s integrity check if one exists, and follow the vendor’s guidance on whether to patch in place, factory-reset or replace.
4. Treat everything that touched the device as stolen: VPN user passwords and sessions, the directory bind account the device uses, certificates and private keys stored on it, and any API tokens configured in it.
5. Look outward from the device: what internal systems did it connect to, from the earliest possible exploitation date, not from today?

The Network Breach Response Checklist has each step with owners and sample answers. Our piece on why edge appliances keep getting breached explains why the window between disclosure and exploitation is now often days.

Why isn’t patching the end of it?

Attackers who exploit edge devices often move fast: they plant web shells or modified files on the appliance, steal the credentials it handles, and use those to log in normally elsewhere. By the time you patch, the attacker may no longer need the flaw. Some implants have survived patching and even firmware upgrades on certain devices, which is why vendors sometimes recommend a full reset or replacement. Work back to the earliest date the device could have been exploited, usually the date the flaw was first exploited in the wild, and scope from there.

How do you decide what to isolate, and how far?

Isolation is a spectrum, not a switch:

• Block egress to known C2 addresses and domains. Cheap and fast, but attackers rotate infrastructure.
• Contain hosts with your endpoint tool: the host stays up for investigation but cannot talk to anything else.
• Segment: cut the affected zone off from the rest, keeping essential flows.
• Disconnect a site or the whole organisation from the internet.

Choose using three questions. How confident are you in the scope? If low, wide isolation risks cutting the wrong things while the attacker sits elsewhere. How critical is the system? Isolating a payment platform has a cost you should state out loud. Will the attacker react? Visible containment can trigger destructive action; if you see backup deletion, mass account changes or encryption starting, isolate hard and immediately and open the ransomware playbook. The Network Isolation Decision Aid walks through these and records the reasoning for the incident log.

How do you know if the domain is compromised?

Look for:

• new or changed members of domain admin, enterprise admin or other privileged groups;
• directory replication requests from machines that are not domain controllers (a sign of credential theft from the directory);
• group policy changes that push scripts, services or scheduled tasks widely;
• remote-management and remote-execution tools appearing on many hosts;
• Kerberos tickets with unusual lifetimes or from unexpected hosts.

If an attacker held domain admin rights, assume they could have taken every password hash in the domain. Recovery is a planned project, not a clean-up: rebuild or verify domain controllers, reset privileged accounts, reset the krbtgt account twice with time between the resets for replication and ticket expiry (follow Microsoft’s published guidance on timing), and review trusts, delegation and group policy. Piecemeal clean-up while the attacker still has a path back usually means doing it twice.

What evidence matters in a network breach?

• Edge-device logs and configuration. Often short retention.
• Firewall, proxy and DNS logs: the best record of C2 and data leaving.
• Flow data (NetFlow or cloud flow logs) for volumes and destinations.
• Endpoint telemetry from servers and domain controllers.
• Domain controller security logs: logons, group changes, replication.
• Memory from key systems if you suspect in-memory implants.

Preserve with chain of custody under the evidence policy. The forensics lab practises triage on these sources.

When does a network breach become a different incident?

Open the ransomware playbook at the first sign of staging: backups deleted, security tools disabled, large archives created. Open the data breach playbook if large outbound transfers line up with sensitive systems. Open the OT playbook if the intrusion approaches the boundary with plant networks. Each hand-off goes through the incident commander under the master plan.

Checklist: network breach response

• Incident declared; earliest possible exploitation date established.
• Device logs, configuration and snapshot collected before patching or reboot.
• Vendor integrity check run; patch, reset or replace decided per vendor guidance.
• VPN sessions killed; credentials, certificates and keys on the device rotated.
• Internal connections from the device scoped back to the earliest date.
• Isolation level chosen and the reasoning logged.
• Privileged group changes, replication requests and GPO changes reviewed.
• Domain recovery planned if domain admin was reached.
• Firewall, DNS, flow and endpoint evidence preserved.
• Ransomware, data breach or OT playbooks opened where signals require.

Rehearse it end to end in the Edge VPN Intrusion Lab.

Frequently asked questions

Is patching an exploited VPN appliance enough? No. A patch closes the flaw but does not remove anything the attacker already installed or took. If the device may have been exploited before the patch, collect its logs and state, run the vendor’s integrity check if one exists, follow the vendor’s rebuild or factory-reset guidance, and rotate every credential, certificate and session secret that was stored on or passed through it.

Should we disconnect the whole network during a breach? Sometimes, but it is rarely the first choice. Full disconnection stops spread but also stops the business and can alert the attacker before you know the scope. Often blocking command-and-control traffic and isolating specific segments buys time to scope. Disconnect fully when you see signs of imminent destructive action, such as backup deletion or mass encryption.

How do you know if Active Directory is compromised? Warning signs include new or changed members of domain admin or other privileged groups, replication requests from machines that are not domain controllers, unexpected group policy changes, new services or scheduled tasks pushed widely, and authentication with tickets that do not match normal patterns. If an attacker held domain admin rights, treat the domain as compromised and plan a controlled recovery.

Why reset the krbtgt password twice? The krbtgt account’s secret signs Kerberos tickets in an Active Directory domain. Active Directory keeps the current and previous password, so a single reset leaves forged tickets based on the old one usable. Resetting twice, with time between the resets for replication and for existing tickets to expire, invalidates both. Follow Microsoft’s guidance on timing to avoid authentication failures.