Isolating a Compromised Mac

When you suspect a Mac in your fleet has been compromised, your first instinct might be to shut it down or wipe it. Resist that urge. Proper isolation contains the threat, prevents lateral movement across your network, and – critically – preserves the volatile evidence you need to understand what happened.

Why Isolation Matters

A compromised Mac is a live threat. While it remains connected to your network, an attacker can:

• Move laterally to other devices and servers on the same network segment
• Exfiltrate data to external command-and-control infrastructure
• Escalate privileges by attacking directory services or MDM infrastructure
• Destroy evidence if they detect your investigation

Isolation severs the attacker’s access while keeping the machine in a state that supports forensic analysis.

Do NOT Power Off the Mac

Critical: Shutting down a compromised Mac destroys volatile data that is essential for investigation – running processes, active network connections, contents of RAM, logged-in sessions, and decrypted FileVault volumes.

Keep the device powered on and awake. If the screen is locked, leave it locked. If the lid is closed on a laptop, open it to prevent sleep (or connect a power adapter and an external display if available). Your goal is to freeze the state, not destroy it.

The only exception: if the Mac is actively encrypting or destroying data (e.g., ransomware in progress), powering off may be the lesser evil. Document this decision.

Network Isolation Methods

Method 1: MDM-Based Isolation (Preferred)

MDM gives you remote, auditable isolation without requiring physical access to the device.

Jamf Pro – Lock Command: Send a Remote Lock command from Jamf Pro. This locks the screen with a custom PIN and message, preventing user interaction while keeping the Mac running and on the network briefly.

Configuration Profile – Network Restriction: Deploy a quarantine configuration profile that:

• Disables Wi-Fi via the Wi-Fi payload (removes all known networks)
• Restricts firewall to block all outbound traffic except your management subnet

# Verify the quarantine profile was applied
profiles list -verbose | grep -i quarantine

Tip: Pre-build a “Quarantine” configuration profile in your MDM and keep it ready to deploy. During an incident, you want to push a profile, not build one from scratch.

Method 2: Network-Level Isolation

If MDM commands are unavailable or the device is unmanaged, isolate at the network layer.

• VLAN reassignment – Move the device’s switch port to an isolated quarantine VLAN with no internet access and no routes to production subnets.
• Firewall block – Add the device’s IP and MAC address to your network firewall’s deny list.
• DHCP reservation – Assign the device to a quarantine network with no default gateway.

Method 3: Local Isolation Commands

If you have SSH or physical access, disable networking directly on the device:

# Disable Wi-Fi interface
networksetup -setairportpower en0 off

# Alternatively, remove all Wi-Fi network configurations
networksetup -removeallpreferredwirelessnetworks en0

# Disable Ethernet (if applicable)
ifconfig en0 down

# Verify no active network interfaces
ifconfig -a | grep "status: active"

Method 4: Physical Isolation

As a last resort when remote methods are unavailable:

• Disconnect Ethernet cables
• Disable Wi-Fi from the menu bar or System Settings
• Disable Bluetooth to prevent any Bluetooth PAN or tethering
• Do NOT close the laptop lid (triggers sleep and loses volatile data)

Remote Lock vs. Remote Wipe

Important: A remote wipe is irreversible and eliminates all forensic evidence. Only issue a wipe when you have explicit authorization from your security lead and legal team, or when the device is physically lost and data protection is the sole priority.

Documenting the State Before Isolation

Before you execute any isolation commands, capture the current state of the device. Even a few quick commands will provide valuable context:

# Record the current date and time
date -u

# Capture running processes
ps aux > /tmp/processes_$(date +%Y%m%d_%H%M%S).txt

# Capture network connections
lsof -i -P -n > /tmp/netconns_$(date +%Y%m%d_%H%M%S).txt

# Capture network interface state
ifconfig -a > /tmp/ifconfig_$(date +%Y%m%d_%H%M%S).txt

# Record logged-in users
who > /tmp/users_$(date +%Y%m%d_%H%M%S).txt

If time is critical and the threat is actively spreading, prioritize isolation over documentation. You can note the exact time you isolated the device and reconstruct some state from MDM and network logs afterward.

Maintaining Chain of Custody

From the moment you begin isolation, maintain a written log:

1. Who performed each action (name and role)
2. What action was taken (exact command or MDM action)
3. When the action was performed (UTC timestamp)
4. Why the action was taken (justification)

This chain of custody log may be required for legal proceedings, regulatory filings, or insurance claims. Keep it in a shared, append-only location (e.g., a ticketing system or shared document with version history).

Communication Protocol

Notify the right people at the right time:

Tip: Do not communicate incident details over the potentially compromised device’s communication channels (email, Slack on the device). Use a separate, trusted channel.

Post-Isolation Next Steps

Once the Mac is isolated:

1. Begin forensic evidence collection – See Collecting Forensic Evidence on macOS for detailed procedures.
2. Follow the IR checklist – Continue through the containment, eradication, and recovery phases in the Mac Admin Incident Response Checklist.
3. Provide the user with a loaner – Keep the compromised device untouched until forensic collection is complete.