2.6 Response Actions and Live Response

Response Actions and Live Response

Introduction

Module 1.4 introduced the response action buttons on the device page and the critical sequence rule: collect the investigation package before isolating the device. This subsection goes deeper into each response action — when to use it, what it actually does at the system level, what side effects it has, and how to use live response for forensic evidence collection that goes beyond what the standard investigation package provides.

Response actions are the bridge between investigation and containment. Investigation tells you what happened. Response actions stop it from continuing and prevent it from spreading. Getting the sequence and selection of response actions right is the difference between containing an incident in minutes and allowing an attacker to operate for hours while you figure out which button to click.

The response action decision framework

When investigation confirms a device is compromised, you face an immediate decision: which response actions to take, and in what order. The decision depends on three factors: the severity of the compromise (is the attacker actively operating or is this historical?), the criticality of the device (is it a standard workstation or a domain controller?), and the scope of the compromise (is this a single device or do you suspect lateral movement to others?).

For active compromise on a standard workstation (the most common scenario — malware executing, C2 connection active, attacker currently operating): the sequence is collect investigation package → isolate the device → contain the user (if account compromise is suspected) → restrict app execution → begin investigation.

For active compromise on a critical server (domain controller, file server, database server): the sequence is the same but each action requires more consideration. Isolating a domain controller disrupts authentication for the entire domain. Isolating a file server cuts off access to shared files for all users. Coordinate with the infrastructure team before isolating critical servers — they need to prepare for the service disruption and may need to activate failover systems.

For historical compromise (the attacker was active days or weeks ago but is not currently operating — detected through threat hunting or retroactive analysis): collection and isolation are still appropriate, but the urgency is lower. The attacker’s persistence mechanisms are the primary concern. Restrict app execution to prevent any dormant payloads from activating while you investigate.

For suspected lateral movement (the compromised device is one of several — the attacker has moved to other systems): contain the user first (to prevent the compromised credentials from being used on additional devices), then isolate each confirmed compromised device individually. Do not isolate devices based on suspicion alone — isolate only devices where investigation confirms compromise.

Device isolation in depth

When you click “Isolate device,” the Defender agent on the device drops all network connections except the MDE management channel. The device cannot communicate with any other device on the network — no file share access, no domain authentication, no internet access, no lateral movement. Only the HTTPS connection to the MDE cloud service remains, enabling continued telemetry, live response sessions, and remote response actions.

Full isolation drops all connections. This is the default and the most secure option. The device is completely cut off from the network. The only way to interact with it remotely is through the MDE portal (live response, investigation package collection, antivirus scans).

Selective isolation (available on some platforms) allows you to specify IP addresses or subnets that remain accessible during isolation. This is useful when the device needs to communicate with a specific service during remediation — for example, maintaining access to a patch management server while the device is being cleaned. Use selective isolation sparingly — every exception is a potential exfiltration or C2 path.

What happens when you isolate: The user on the device loses all network connectivity. They cannot access email, file shares, websites, or internal applications. They will call the help desk. Prepare for this by notifying the user (if possible) or the user’s manager before isolating. If the user is the suspected insider threat, do not notify them — coordinate with HR and legal.

The device continues to function locally — the user can still use locally installed applications and access local files. They just cannot communicate over the network. This is by design — you want the device to remain operational enough for the user to save any open work (if appropriate) while the network threat vector is closed.

Releasing isolation: After remediation is complete (malware removed, persistence cleared, credentials reset), release the isolation from the device page by clicking “Release from isolation.” Network connectivity restores within seconds. Verify the device can authenticate, access network resources, and that MDE telemetry continues to flow normally.

Contain device (for unmanaged devices)

The “Contain device” action is different from isolation. It targets unmanaged devices — devices on your network that do not have the MDE sensor installed. When you contain an unmanaged device, the MDE portal instructs every onboarded device in the network to block all communication with the contained device’s IP and MAC address.

This is one of the few ways to respond to a compromised device that you cannot directly manage — a printer, IoT device, legacy server, or BYOD device that cannot run the MDE sensor. The containment is enforced at the network level by every onboarded device, creating a virtual quarantine around the unmanaged device.

To contain an unmanaged device, navigate to Assets → Devices, find the device (it appears through device discovery — subsection 2.2), and select “Contain device.” The containment takes effect within minutes as onboarded devices receive the blocking instruction.

Limitations: Contain device only blocks communication from onboarded devices. If other unmanaged devices exist on the same network segment, they can still communicate with the contained device. For full containment of an unmanaged device, you need network-level controls (switch port shutdown, VLAN isolation) in addition to MDE’s contain device action.

Contain user

The “Contain user” action blocks a compromised user account from accessing any onboarded device. When an account is contained, the MDE agent on every onboarded device blocks authentication attempts, lateral movement, and network access by that user.

This action is critical during account compromise scenarios (AiTM phishing, credential theft, pass-the-hash). The attacker has valid credentials and is using them to move between devices. Resetting the password stops future authentication, but the attacker may already have active sessions or tokens that survive a password reset. Contain user immediately blocks the compromised identity at the endpoint level — even if the attacker has a valid token, the endpoint refuses the connection.

Contain user works through Defender for Identity (for on-premises AD accounts) or directly through Entra ID (for cloud-native accounts). When attack disruption triggers automatically, contain user is one of the actions it can take without analyst approval.

Live response: advanced forensic collection

Module 1.4 introduced live response basics. This subsection covers the advanced forensic collection capabilities that make live response the primary tool for post-isolation evidence gathering.

The live response library is a centralized repository of scripts that can be deployed to any device during a live response session. Upload PowerShell or Bash scripts to the library (Settings → Endpoints → Advanced features → Live response library), and any analyst can run them during investigations. This enables standardized forensic collection across your SOC team — every analyst runs the same collection script, producing consistent evidence regardless of who handles the incident.

Building a forensic collection script. A comprehensive collection script gathers artifacts beyond what the standard investigation package includes:

Browser history and bookmarks (reveals phishing URLs visited, credential theft pages, and attacker-accessed web applications). Recent file access records from the NTFS $MFT (shows exactly which files the attacker accessed, even if they did not modify them). PowerShell transcript logs and script block logs (captures the exact PowerShell commands executed, including decoded versions of encoded commands). Event Tracing for Windows (ETW) session data (captures kernel-level activity that the standard investigation package does not include). Active Directory cached credentials (on domain-joined devices, reveals which domain accounts have cached credentials that the attacker could extract). Clipboard contents (may contain copied credentials, data, or command output).

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35

# Example: Forensic collection script for live response library
# Save as Collect-ForensicArtifacts.ps1 and upload to the library

$OutputPath = "C:\ForensicCollection"
New-Item -ItemType Directory -Path $OutputPath -Force | Out-Null

# Browser history (Chrome)
$ChromeHistory = "$env:LOCALAPPDATA\Google\Chrome\User Data\Default\History"
if (Test-Path $ChromeHistory) {
    Copy-Item $ChromeHistory "$OutputPath\chrome_history.sqlite" -Force
}

# PowerShell transcript logs
$TranscriptPath = "$env:USERPROFILE\Documents\PowerShell_transcript*"
Get-ChildItem $TranscriptPath -ErrorAction SilentlyContinue |
    Copy-Item -Destination $OutputPath -Force

# Recent files (last 48 hours)
Get-ChildItem -Path C:\Users -Recurse -File -ErrorAction SilentlyContinue |
    Where-Object { $_.LastWriteTime -gt (Get-Date).AddHours(-48) } |
    Select-Object FullName, Length, LastWriteTime, CreationTime |
    Export-Csv "$OutputPath\recent_files.csv" -NoTypeInformation

# Scheduled tasks (detailed)
Get-ScheduledTask | Where-Object { $_.State -ne "Disabled" } |
    Select-Object TaskName, TaskPath, State,
    @{N='Actions';E={$_.Actions.Execute}},
    @{N='Triggers';E={$_.Triggers.StartBoundary}} |
    Export-Csv "$OutputPath\scheduled_tasks.csv" -NoTypeInformation

# DNS cache
Get-DnsClientCache |
    Export-Csv "$OutputPath\dns_cache.csv" -NoTypeInformation

Write-Output "Collection complete. Files saved to $OutputPath"

To use this script during an investigation: initiate a live response session to the device, run run Collect-ForensicArtifacts.ps1, wait for completion, then download the output files with getfile "C:\ForensicCollection\chrome_history.sqlite" (and each other output file).

Restrict app execution

The “Restrict app execution” action limits which applications can run on the device to only Microsoft-signed executables. This effectively creates an emergency application allowlist that prevents any attacker tool, custom malware, or unsigned script from executing while maintaining core Windows functionality.

Use this action when you have confirmed malware on a device but cannot immediately isolate it (for example, a critical server that cannot lose network connectivity) or when you need to prevent dormant payloads from activating while you investigate. The restriction takes effect within minutes and can be reversed from the device page when remediation is complete.

Operational impact: Restrict app execution blocks all non-Microsoft-signed applications. This means line-of-business applications, custom scripts, third-party tools, and even some components of legitimate software will not run. This is an emergency measure, not a permanent configuration. Communicate the impact to the affected user and their manager, and plan to release the restriction as soon as the investigation and remediation are complete.

Run antivirus scan

The “Run antivirus scan” action triggers a Microsoft Defender Antivirus scan on the device — either a quick scan (common file locations and running processes) or a full scan (all files on all drives). This action works even when a third-party antivirus is the primary protection (Defender Antivirus runs in passive mode but can still perform on-demand scans).

When to use: After initial containment (isolation + app restriction), run a full antivirus scan to identify and quarantine all malicious files on the device. Also run a scan post-remediation to verify that all malware has been removed. Do not use an antivirus scan as your first response to an active compromise — containment (isolation) takes priority because a scan takes 30-60 minutes while the attacker continues to operate.

The Action Center

Every response action you take is logged in the Action Center (accessible from the Defender portal navigation). The Action Center shows two tabs: Pending (actions awaiting approval when automation is in semi-auto mode) and History (all completed actions with timestamps, the analyst who initiated them, the target device, and the result).

The History tab is your operational audit trail. During an incident review, the Action Center shows exactly when each containment action was taken, who took it, and whether it succeeded. This data goes directly into the incident report timeline (Module 14). For compliance and legal purposes, the Action Center provides evidence that containment actions were taken promptly and appropriately.

Check the Pending tab at every shift start. If your automation level is semi-auto, pending actions represent AIR recommendations that are waiting for analyst approval. Pending actions that sit unapproved for hours mean your automated investigation engine identified a remediation need but no one authorized it — the threat remains uncontained. Review and approve (or reject with reason) all pending actions within 30 minutes of the start of each shift.

Knowledge check