How to Isolate a Compromised Endpoint: Network, Identity and Evidence Steps

Cutting a compromised laptop or server off the network takes one click, but doing it in the wrong order destroys the evidence you need and leaves the attacker holding the credentials and sessions that machine gave them. Network isolation stops new commands and lateral movement from that host. It does nothing about the passwords, Kerberos tickets, browser cookies and tokens that were on the device, which work from anywhere. This guide is the single-host procedure: what to capture first, how to isolate with an EDR agent or at the network layer, which identity actions to take in parallel, how to verify the isolation holds and how to release the device safely. It is for SOC analysts, endpoint engineers and incident responders. For the strategic decision of when to contain and when to observe, see the Incident Scoping and Containment Strategy Guide; for a whole-estate outbreak, use the Malware Outbreak Playbook.

Microsoft Defender for Endpoint and Microsoft Entra ID appear below as one worked example, so that the steps can name real actions. The procedure itself is platform-neutral: other EDR, network and identity platforms provide equivalent isolation, containment, release and session revocation actions under their own names, and the same steps apply to them. Use the action names, roles and limits in your own platform's current documentation.

Key takeaways

• Capture volatile evidence first, then isolate. RFC 3227 places the routing table, ARP cache, process table and memory near the top of the order of volatility, after registers and cache, and warns: "Don't shutdown until you've completed evidence collection."
• Prefer agent isolation over pulling the cable. EDR isolation keeps the agent talking to its console, so you can still collect data, run scans and watch the host; a physical disconnect blinds you too.
• Isolation is not identity containment. Every account that signed in to the host must be treated as exposed: revoke its sessions, reset its password and check where its credentials were used next.
• Plan for the awkward cases. Full-tunnel VPNs, web proxies, servers with dependants and hypervisors all change what isolation does; decide these in advance, not mid-incident.
• Release is a decision, not a timeout. Some isolation actions lift automatically; track every isolated device and release only after eradication or rebuild is confirmed.

When you need this

• Confirmed malicious activity on one host: hands-on-keyboard behaviour, credential dumping alerts (T1003.001 LSASS Memory), ransomware precursors or a command and control beacon.
• Infostealer or session theft: malware that harvests browser passwords and cookies (T1555.003, T1539). Isolation stops further exfiltration, and the identity steps below deal with what already left. See the Infostealer Logs and Session Token Abuse Guide.
• Lateral movement source: the host is being used to reach others through remote services (T1021) or pass the hash (T1550.002).
• Unmanaged or rogue device: a device with no agent needs network-level containment instead; see the Rogue Device on Network Playbook.

If the incident looks like a wider intrusion with several footholds, pause before isolating a single host. NCSC warns that an attacker "might react to your actions, or bury themselves more deeply in the network", so coordinate with the incident commander before acting on one machine in a multi-host intrusion.

Before you start

1. Confirm the device: hostname, device ID in the EDR console, IP and MAC address, owner, business function. Check it is not a shared IP or a network device.
2. Check the business impact: a domain controller, hypervisor host or production server has dependants. Isolating a Hyper-V host, for example, blocks traffic to all its child virtual machines, so the service owner or incident commander decides.
3. Check connectivity type: is the device on a full-tunnel VPN or behind a proxy? Check what your platform documents for these set-ups. In the worked example, Microsoft recommends a split-tunnelling VPN so an isolated device can still reach the service, and selective isolation where web proxies (PAC, WPAD, static) are in use, so the device can recover from isolation.
4. Confirm your rights: in Defender for Endpoint, isolation needs at least the Active remediation actions role plus access to the device's device group.
5. List the identities on the host: the signed-in user, recent interactive sign-ins, service accounts running services or scheduled tasks, and any admin who connected during the suspected window.
6. Open the incident record: note the time (UTC) of every action from here on. NCSC recommends recording "decisions made, actions taken, data captured (or missing)".

Step-by-step

Step 1: Capture volatile evidence

If the attacker is not actively destroying data, spend the first minutes on what isolation or a reboot would lose. Follow the order of volatility from RFC 3227:

RFC 3227 also warns that "simply disconnecting or filtering from the network may trigger 'deadman switches'". If you see signs of destructive malware, isolate first and accept the evidence loss. Details on acquisition are in the Memory Forensics Guide and Disk Imaging and Forensic Acquisition Guide.

Step 2: Isolate the device

Choose the method by what you have:

In the Defender portal the action is on the device page, Isolate device, with a comment. Microsoft documents that an offline device has the action retried for up to three days, that isolation lifts automatically after seven days, and that on Linux an administrator modifying or adding an iptables rule removes isolation, so leave those rules unchanged while the device is isolated. Other platforms document their own retry, expiry and release behaviour; record it in your runbook. Add the device to your isolated-device tracker with an owner and a review date.

Step 3: Stop malicious execution

Isolation stops network activity, not local activity. Terminate the malicious processes and quarantine the files the EDR identified, then run a full antivirus scan. If you need tighter control while investigating, Defender for Endpoint's Restrict app execution applies a code integrity policy that lets only Microsoft-signed files run; remove it with Remove app restrictions when done. These map to D3FEND D3-PT Process Termination.

Step 4: Contain the identities that touched the host

Run this in parallel with Step 2, because credentials stolen from the host are already off the network. Our recommended order:

1. Signed-in user: revoke sessions and refresh tokens at the identity provider. In Microsoft Entra ID that is Revoke sessions on the user, or Revoke-MgUserSignInSession. Access tokens remain valid until expiry (one hour by default) except in apps that support Continuous Access Evaluation, and application session cookies must be ended in each application. The revocation matrix by platform is in the Session Token Theft Response Playbook.
2. Password reset: reset the user's password. For hybrid accounts, Microsoft's emergency revocation guidance resets the on-premises password twice to mitigate pass the hash, after disabling the account where needed.
3. Device identity: disable the device object in the directory (for Entra ID, Update-MgDevice -AccountEnabled:$false for the user's registered devices), so device-based Conditional Access no longer trusts it.
4. Privileged accounts: any admin account that signed in interactively or ran a service on the host during the window is treated as compromised: reset, revoke and review its recent activity.
5. Service accounts and secrets on the host: rotate credentials stored in configuration files, scheduled tasks, CLI profiles and environment variables. Developer machines are dense with these; see Developer endpoints as NHI stores.
6. Local administrator: rotate the local admin password once the device can reach the directory again (Windows LAPS: Set-LapsADPasswordExpirationTime then policy processing, or Reset-LapsPassword on the device). See the LAPS Guide.

Step 5: Check where the credentials went next

Search identity provider sign-in logs, VPN logs and cloud audit logs for every identity from Step 4, from the start of the suspected window, filtering for sources other than the isolated host. Any hit expands the incident scope beyond one endpoint.

Decision guidance

• Full or selective isolation: full by default; selective only for a documented reason (proxy recovery, the need to reach the user), with exclusions kept minimal.
• Isolate now or watch: commodity malware on one workstation, isolate immediately. Suspected targeted intrusion, the incident commander decides, because isolating one host can alert the attacker while other footholds remain.
• Clean or rebuild: our recommendation is to rebuild any device where the attacker had administrative or SYSTEM control, and to clean only where the EDR shows a contained, fully understood infection.
• Small organisations: pre-approve the SOC or managed service provider to isolate workstations without escalation, and keep a one-page identity checklist next to the isolation button.
• Large organisations: separate pre-approvals for workstations (SOC) and servers (service owner), automated isolation for high-confidence detections, and a tracker that reconciles isolated devices daily.

Verify it worked

• Isolation state: the console shows the action as completed (in Defender for Endpoint, in the Action center and device timeline), not pending.
• Network: firewall, proxy and DNS logs show no traffic from the device's IP after the isolation time other than the agent channel.
• Identity: no new sign-ins or token refreshes for the contained identities from any source; sign-ins after reset show fresh MFA.
• Telemetry: the agent is still reporting, so tampering or an agent crash would be visible. See the EDR Tampering and BYOVD Response Playbook.

Release and rollback

1. Prerequisites: evidence captured and hashed, root cause understood, malware removed or the device rebuilt, identities reset.
2. Release: in Defender for Endpoint, Release from isolation on the device page. Record who approved it.
3. Watch: our recommendation is heightened monitoring of the device and its users for 14 days after release.
4. Rollback of a wrong isolation: if the isolation was a false positive, release, record the business impact and tune the detection; do not undo the identity resets unless they are proven unnecessary.

Common failure patterns

• Isolating before capturing memory when there was time, losing the injected code and the attacker's live connections.
• Treating isolation as the end of containment while the stolen browser cookies and refresh tokens keep working from the attacker's infrastructure.
• Forgetting the automatic release of a time-limited isolation, so a device rejoins the network unreviewed.
• Isolating a host with dependants (hypervisor, file server, domain controller) without the service owner, causing an outage larger than the incident.
• Reimaging straight away without a disk image, leaving no way to answer later questions from regulators or insurers.
• Missing service account secrets stored on the host, which the attacker then uses from elsewhere.

Metrics

• Time from high-confidence detection to isolation completed (our target: under 15 minutes for workstations).
• Time from isolation to session revocation for every identity on the host.
• Percentage of isolations where memory was captured first.
• Number of devices isolated longer than their review date.
• Percentage of endpoints with a working EDR isolation capability (agent healthy and in a device group with response rights).

Framework mapping

Practitioner checklist

• Confirm device identity, dependants, VPN and proxy situation before acting.
• Capture memory and an investigation package unless destruction is under way.
• Isolate with the EDR agent; fall back to network quarantine if the agent is unavailable.
• Stop malicious processes and quarantine files; isolation alone does not stop local execution.
• Revoke sessions, reset passwords and disable the device object for every identity on the host.
• Rotate service account secrets and the local admin password.
• Hunt for use of those credentials from other sources.
• Track every isolated device with an owner and review date; release only after eradication.

Standards and references

• IETF: RFC 3227 Guidelines for Evidence Collection and Archiving (BCP 55)
• NIST: SP 800-61 Rev. 3 Incident Response Recommendations and Considerations for Cybersecurity Risk Management
• NCSC: Cyber incident response processes
• Microsoft Learn: Take response actions on a device in Defender for Endpoint
• Microsoft Learn: Revoke user access in an emergency in Microsoft Entra ID
• Microsoft Learn: Windows LAPS with Active Directory

Related NHI Mgmt Group resources: Incident Scoping and Containment Strategy Guide · EDR Guide · Digital Forensics (DFIR) Guide · Identity Incident Response Playbook