In Part 1 of this series I walked through the Microsoft Defender product ecosystem — what each product does, how the pieces fit together, and why the integrated stack matters more than any single tool. Part 2 is where things get hands-on.

I’m going to cover three areas that I’ve spent a lot of time with in production environments: Attack Surface Reduction (ASR) rules beyond the basic toggles, Live Response for real-time investigation and containment, and KQL hunting playbooks in the Defender portal. These aren’t theoretical — every example here comes from something I’ve actually run against a tenant or used during a real incident.

Let’s get into it.

1 — Advanced ASR: Beyond the Basic Toggles

Most guides tell you to enable ASR rules and move on. In practice, that’s where the headaches start. ASR rules touch real behaviour on endpoints — Office macros, LOB applications, PowerShell execution patterns, process injection — and if you push everything to Block without understanding the blast radius, you will break things. I’ve seen it happen more than once.

The approach I use is a proper audit-first, ring-based rollout. It’s not glamorous, but it’s the only way to avoid a 2am call from someone saying Outlook stopped launching.

The ASR Rules That Actually Matter

There are 16+ ASR rules, but in my experience these are the ones that carry the most defensive weight — and also the most compatibility risk if you enable them blind:

Deploying via Intune: The Ring Approach

I deploy ASR rules through Intune Endpoint Security policies, not Group Policy — it gives me per-device status, reporting, and the ability to assign to dynamic AAD groups for ring control. The deployment structure I use looks like this:

Reviewing ASR Events in MDE

You can see ASR events in the MDE portal under Reports > Attack Surface Reduction, but I find KQL in Advanced Hunting much more useful because I can filter by rule GUID, group by device or user, and identify patterns quickly. Here’s the query I use for an ASR audit review:

// ASR audit events — last 30 days
DeviceEvents
| where Timestamp > ago(30d)
| where ActionType == "AsrOfficeChildProcessAudited"
     or ActionType startswith "Asr"
| summarize EventCount = count(),
            AffectedDevices = dcount(DeviceName),
            AffectedUsers = dcount(InitiatingProcessAccountName)
     by ActionType, InitiatingProcessFileName, InitiatingProcessFolderPath
| sort by EventCount desc

The output tells me which processes are triggering which rules, across how many devices, and who’s running them. If I see a legitimate LOB app hitting 40+ events a day, that’s a rule exclusion candidate. If I see something unexpected in an unusual path, that’s a hunt lead.

2 — Live Response: Real-Time Investigation and Containment

Live Response is one of MDE’s most powerful capabilities and also one of the most underused. It gives you a remote shell into any onboarded device — without needing RDP, VPN, or a third-party tool. During an incident, this is the difference between hours of back-and-forth and getting answers in minutes.

I’ve used Live Response to pull suspicious files for analysis, terminate malicious processes, drop remediation scripts, collect forensic artefacts, and contain a device while the user stays on a call with us. It’s become a standard part of my incident workflow.

Commands I Actually Use

Live Response has a command set that’s a mix of file operations, process management, and script execution. Here are the ones that come up most in real incidents:

# Pull a suspicious file to the portal library for analysis
getfile "C:\Users\victim\AppData\Local\Temp\sus.exe"

# Check file hash on device before pulling
run Get-FileHash.ps1 -parameters "-Path 'C:\Temp\sus.exe'"

# List running processes — pipe to findstr for quick filter
processes

# Terminate a specific process by PID
remediate process 4812

# Collect prefetch files (useful for execution timeline)
getfile "C:\Windows\Prefetch\SUS.EXE-*.pf"

# Upload a script to the library first (MDE portal → Library)
# Then run it on the device:
run Remediate-PersistenceKeys.ps1

# With parameters:
run Collect-ForensicArtefacts.ps1 -parameters "-OutputPath 'C:\Temp\forensics'"

My Incident Workflow with Live Response

When I get an alert that warrants direct device access, this is the rough sequence I follow:

3 — KQL Hunting Playbooks

Advanced Hunting in MDE (and Sentinel) runs on KQL — the Kusto Query Language. If you’re new to it, it looks intimidating. Once it clicks, you won’t want to go back to clicking through dashboards. KQL lets me ask specific questions of endpoint telemetry at scale: “which devices ran a PowerShell command that downloaded something in the last 7 days?” That’s a query, not a manual process.

Below are the playbook queries I reach for most often. These aren’t academic — they’ve all surfaced real findings at some point.

Playbook 1: PowerShell Download Cradle Detection

Malware loves PowerShell download cradles — IEX (New-Object Net.WebClient).DownloadString(), Invoke-WebRequest, curl wrappers, and so on. This query hunts for PowerShell processes with command lines containing download patterns:

DeviceProcessEvents
| where Timestamp > ago(7d)
| where FileName in~ ("powershell.exe", "pwsh.exe")
| where ProcessCommandLine has_any (
    "DownloadString", "DownloadFile", "WebClient",
    "Invoke-WebRequest", "iwr ", "curl ", "wget ",
    "BitsTransfer", "Start-BitsTransfer"
)
| project Timestamp, DeviceName, AccountName,
          ProcessCommandLine, InitiatingProcessFileName,
          InitiatingProcessCommandLine
| sort by Timestamp desc

Playbook 2: LSASS Access Attempts

Credential dumping against LSASS is a staple of post-exploitation. Even with Credential Guard and ASR protecting LSASS, I hunt for access attempts as an early indicator — sometimes the attempt alone is worth an alert.

DeviceEvents
| where Timestamp > ago(7d)
| where ActionType == "OpenProcessApiCall"
| where FileName == "lsass.exe"
| where InitiatingProcessFileName !in (
    "MsMpEng.exe", "svchost.exe", "csrss.exe",
    "wininit.exe", "lsm.exe", "services.exe"
)
| project Timestamp, DeviceName, InitiatingProcessFileName,
          InitiatingProcessCommandLine, InitiatingProcessFolderPath,
          AccountName
| sort by Timestamp desc

Playbook 3: Lateral Movement via PsExec / SMB

PsExec-style lateral movement leaves a recognisable pattern in network and process events. This query joins network connections to process events to surface the combination of remote execution and SMB connectivity:

// Devices making remote service/process creation over SMB
let SuspiciousProcs = DeviceProcessEvents
| where Timestamp > ago(1d)
| where InitiatingProcessFileName in~ (
    "psexec.exe", "psexec64.exe", "paexec.exe"
)
| project DeviceName, AccountName, ProcessCommandLine, Timestamp;
let SMBConns = DeviceNetworkEvents
| where Timestamp > ago(1d)
| where RemotePort == 445
| project DeviceName, RemoteIP, RemoteUrl, Timestamp;
SuspiciousProcs
| join kind=inner SMBConns on DeviceName
| where abs(Timestamp - Timestamp1) < 5m
| project DeviceName, AccountName, ProcessCommandLine,
          RemoteIP, RemoteUrl, Timestamp
| sort by Timestamp desc

Playbook 4: Persistence via Scheduled Tasks

Scheduled task creation is a classic persistence mechanism. Attackers love it because it survives reboots and is easy to blend into legitimate noise. This query surfaces new scheduled task creations along with the command they execute — the payload is almost always in the task action:

DeviceEvents
| where Timestamp > ago(7d)
| where ActionType == "ScheduledTaskCreated"
| extend TaskDetails = parse_json(AdditionalFields)
| extend TaskName    = tostring(TaskDetails.TaskName),
         TaskContent  = tostring(TaskDetails.TaskContent)
| where TaskContent has_any (
    "powershell", "cmd.exe", "wscript",
    "cscript", "mshta", "regsvr32", "rundll32"
)
| project Timestamp, DeviceName, AccountName,
          TaskName, TaskContent, InitiatingProcessFileName
| sort by Timestamp desc

Turning Playbooks into Custom Detections

Any query in Advanced Hunting can be promoted to a Custom Detection rule — MDE will run it on a schedule and generate alerts automatically. I do this for the high-signal queries once I’ve tuned out the false positives. Go to the query in Advanced Hunting, click Create detection rule, set the frequency (I usually start at 24h for noisy queries, 1h for high-confidence ones), and map the alert entity to a device or user.

The scheduled task persistence query above is one I have running as a custom detection in every tenant I manage. It’s generated real findings — not just in red team exercises.

Wrapping Up

ASR, Live Response, and KQL hunting aren’t separate features — they’re part of a continuous loop. ASR generates events that you hunt with KQL. KQL surfaces indicators that you investigate with Live Response. Live Response findings inform ASR exclusions and custom detection rules. Once you build that loop into your workflow, Defender for Endpoint stops feeling like a compliance checkbox and starts functioning like a genuine investigation platform.

In Part 3 I’ll be covering Defender for Identity — lateral movement detection, attack paths in Entra, and how the identity-layer telemetry slots into the incidents you’re already seeing in MDE.

If anything in this post maps to something you’ve hit in your environment, or if you have a KQL query you’d add to the playbook list, drop it in the comments — I always read them.