Network Isolation of Compromised Systems

IR AnalystSwitch roles in the top navigation to see different perspectives.

Isolate compromised systems from the network to stop lateral movement and data exfiltration while preserving forensic access. Use EDR network containment where available; fall back to switch-level or firewall ACLs.

Actions

  1. 1.Initiate EDR network containment on the compromised host (CrowdStrike: `falconctl -s --cid | containment enable`, Defender: Isolate device from MDE portal or via API `POST /api/machines/{id}/isolate`).
  2. 2.If EDR containment is not available, implement switch-port isolation: move the host VLAN to a quarantine VLAN with no routes except to the forensic workstation. Document the original VLAN assignment.
  3. 3.Deploy firewall rules to block the host IP from all outbound communication except the forensic subnet: `iptables -I FORWARD -s <compromised_ip> -j DROP` or equivalent on your perimeter firewall.
  4. 4.Verify isolation is effective: from a separate host, attempt to ping, SSH, and reach SMB (445) on the isolated host. Confirm all connections are refused or timed out.
  5. 5.For ransomware: immediately block all SMB (445/tcp) and RDP (3389/tcp) traffic between segments to prevent encryption spread. Use firewall rules: `deny tcp any any eq 445` and `deny tcp any any eq 3389` on inter-VLAN ACLs.

Queries

DeviceNetworkEvents | where DeviceName == "COMPROMISED_HOST" | where Timestamp > ago(1h) | summarize ConnectionCount=count() by RemoteIP, RemotePort, ActionType | order by ConnectionCount desc
index=firewall sourcetype=paloalto_traffic src_ip=COMPROMISED_IP action=allowed | stats count by dest_ip, dest_port, app | sort -count | head 50
index=network sourcetype=cisco:asa src_ip=COMPROMISED_IP OR dst_ip=COMPROMISED_IP | timechart span=5m count by action | where action="permitted"

Notes

  • CRITICAL: Before isolating, ensure volatile memory has been captured if the host is still powered on. Isolation may trigger anti-forensic kill switches in some malware.
  • Maintain a list of all isolation actions taken with timestamps for the containment log -- these must be reversed during recovery.

Common Blockers

No PCAP or NetFlow Data Available

There is no packet capture, NetFlow, or network metadata available for the timeframe of interest. Without network data it is difficult to confirm data exfiltration volumes, C2 channel details, or lateral movement paths.

Need Data from External Vendor or MSP

Critical evidence resides with a third-party managed service provider, SaaS vendor, or hosting company. Your team has no direct access and must navigate contractual, legal, and technical hurdles to obtain logs or images.

Legal Requesting Preservation Conflicts with Containment

Legal counsel has issued a preservation hold requiring that certain systems, mailboxes, or data stores remain untouched. This directly conflicts with containment actions like reimaging hosts, resetting accounts, or blocking network segments.

Systems Encrypted by Ransomware -- Normal Artifact Collection Blocked

Ransomware has encrypted the filesystem on affected hosts. Standard artifact collection tools cannot read files, registry hives, or event logs from the encrypted volume. The operating system may not boot.

Shared Cloud Environment Complicates Isolation

The compromised workload runs in a multi-tenant cloud environment (shared subscription, Kubernetes cluster, or PaaS) where isolation actions may impact other tenants or business-critical services sharing the same infrastructure.

Backups May Be Compromised -- Cannot Trust for Recovery

Backup integrity is uncertain. The attacker may have been present in the environment long enough to have compromised backup copies, planted persistence mechanisms in backup images, or encrypted/deleted backup repositories.