Agent Foskett Academy • Lesson 107 • Hunting Playbook Series

Hunting Playbook: Persistence Mechanisms in Microsoft Defender XDR.

The password was reset. The malicious process was stopped. The obvious alert was closed.

But the attacker had already prepared a way back in.

A scheduled task. A service. A registry run key. A startup folder entry. A WMI subscription.

Agent Foskett knew the investigation was not finished when the first threat was removed.

The real question was simple: what did the attacker leave behind?

Start Lesson 107 Back to Academy

Agent Foskett Academy lesson hunting persistence mechanisms in Microsoft Defender XDR

Lesson overview

Learn how to hunt for attacker persistence by analysing scheduled tasks, services, registry run keys, startup folder changes, WMI activity and suspicious post-compromise behaviour inside Microsoft Defender XDR.

Identify common persistence locations

Review registry, service and task activity

Correlate process and device evidence

Separate administration from attacker persistence

Why persistence mechanisms matter

Persistence is how attackers survive password resets, process termination, reboots and partial clean-up. A system can look remediated while a hidden mechanism quietly prepares the next execution.

Persistence keeps access aliveAttackers create tasks, services, registry entries or startup items so access can resume after reboot or remediation.

Persistence often looks administrativeMany persistence techniques use normal Windows features that administrators also use, which makes context essential.

The timeline mattersThe key question is not only what changed, but when it changed and what process or account caused the change.

The persistence hunting workflow

Agent Foskett hunts persistence by looking for durable changes that allow code to execute again later.

1. Start with the affected deviceIdentify the device, user and timeframe connected to the original compromise or suspicious execution.

2. Hunt scheduled tasksReview new or modified scheduled tasks, especially those created by unusual processes or user accounts.

3. Review servicesLook for new services, modified service paths and suspicious binaries launched by service control activity.

4. Check registry run keysInvestigate registry locations commonly used to launch programs at logon or startup.

5. Review startup folders and WMILook for startup folder writes, script drops and WMI event subscription behaviour.

6. Build the timelineCombine process, registry, file and device events to determine whether persistence was created after compromise.

Step 1 — Start with suspicious task creation

Scheduled tasks are one of the most common ways attackers maintain access after initial execution.

let TimeFrame = 14d;
DeviceProcessEvents
| where Timestamp > ago(TimeFrame)
| where FileName in~ ("schtasks.exe", "powershell.exe", "cmd.exe")
| where ProcessCommandLine has_any ("/create", "Register-ScheduledTask", "New-ScheduledTask")
| project Timestamp,
          DeviceName,
          AccountName,
          FileName,
          ProcessCommandLine,
          InitiatingProcessFileName
| order by Timestamp desc

Step 2 — Hunt suspicious service creation

A malicious service can provide execution after reboot and can hide behind legitimate-looking service names.

let TimeFrame = 14d;
DeviceProcessEvents
| where Timestamp > ago(TimeFrame)
| where FileName in~ ("sc.exe", "powershell.exe", "cmd.exe")
| where ProcessCommandLine has_any (" create ", "New-Service", "binPath", "start= auto")
| project Timestamp,
          DeviceName,
          AccountName,
          FileName,
          ProcessCommandLine,
          InitiatingProcessFileName
| order by Timestamp desc

Step 3 — Review registry run key changes

Registry run keys are frequently abused to launch payloads when a user signs in.

let TimeFrame = 14d;
DeviceRegistryEvents
| where Timestamp > ago(TimeFrame)
| where RegistryKey has_any ("\Run", "\RunOnce", "\Winlogon", "\Policies\Explorer\Run")
| project Timestamp,
          DeviceName,
          InitiatingProcessAccountName,
          InitiatingProcessFileName,
          RegistryKey,
          RegistryValueName,
          RegistryValueData,
          ActionType
| order by Timestamp desc

Step 4 — Look for startup folder file creation

Startup folders are simple, noisy and effective. Attackers may drop shortcuts, scripts or executable payloads there.

let TimeFrame = 14d;
DeviceFileEvents
| where Timestamp > ago(TimeFrame)
| where FolderPath has_any ("\Startup\", "Start Menu\Programs\Startup")
| project Timestamp,
          DeviceName,
          InitiatingProcessAccountName,
          InitiatingProcessFileName,
          FileName,
          FolderPath,
          SHA256,
          ActionType
| order by Timestamp desc

Step 5 — Hunt WMI persistence indicators

WMI event subscriptions can be used to trigger execution without obvious startup files or services.

let TimeFrame = 14d;
DeviceProcessEvents
| where Timestamp > ago(TimeFrame)
| where ProcessCommandLine has_any ("__EventFilter", "CommandLineEventConsumer", "ActiveScriptEventConsumer", "wmic", "Set-WmiInstance")
| project Timestamp,
          DeviceName,
          AccountName,
          FileName,
          ProcessCommandLine,
          InitiatingProcessFileName
| order by Timestamp desc

Step 6 — Build the persistence timeline

A useful persistence investigation should show which account and process created the durable change, and what happened before and after.

let TimeFrame = 14d;
let SuspiciousDevice = "DEVICE-01";
union isfuzzy=true
(
    DeviceProcessEvents
    | where Timestamp > ago(TimeFrame)
    | where DeviceName =~ SuspiciousDevice
    | where ProcessCommandLine has_any ("schtasks", "sc.exe", "New-Service", "Register-ScheduledTask", "wmic")
    | project Timestamp, DeviceName, EvidenceType="Process", AccountName, FileName, Evidence=ProcessCommandLine
),
(
    DeviceRegistryEvents
    | where Timestamp > ago(TimeFrame)
    | where DeviceName =~ SuspiciousDevice
    | where RegistryKey has_any ("\Run", "\RunOnce", "\Winlogon")
    | project Timestamp, DeviceName, EvidenceType="Registry", AccountName=InitiatingProcessAccountName, FileName=InitiatingProcessFileName, Evidence=strcat(RegistryKey, " ", RegistryValueData)
),
(
    DeviceFileEvents
    | where Timestamp > ago(TimeFrame)
    | where DeviceName =~ SuspiciousDevice
    | where FolderPath has "Startup"
    | project Timestamp, DeviceName, EvidenceType="File", AccountName=InitiatingProcessAccountName, FileName, Evidence=FolderPath
)
| order by Timestamp asc

Common persistence investigation clues

Unusual parent processA persistence mechanism created by Office, browser, script host or a LOLBin deserves closer inspection.

Strange command linesEncoded commands, remote URLs, temp paths and hidden windows can indicate attacker-created persistence.

Recently created autorunsNew services, scheduled tasks, run keys and startup files created after suspicious sign-in activity are important timeline anchors.

User context mismatchPersistence created by an unexpected user, service account or admin account may indicate credential misuse.

Network follow-upIf a persistence mechanism launches a process that connects externally, pivot into DeviceNetworkEvents.

Repeated executionScheduled tasks or services that run repeatedly can show attacker access attempts after the initial compromise.

False positives to consider

Software deployment toolsIntune, SCCM, RMM tools and installers regularly create tasks, services and registry keys.

Security toolingEDR agents, vulnerability scanners and backup tools often create persistent services by design.

Legitimate administrationAdministrators may use scheduled tasks or services for maintenance. Confirm change tickets or expected activity.

Application updatersBrowsers, collaboration tools and business applications frequently maintain update tasks and services.

User automationPower users may create startup scripts or scheduled tasks. Validate ownership and business purpose.

Baseline firstPersistence hunting improves when defenders know what normal autoruns look like in their environment.

Investigation checklist

Was persistence created after compromise?Compare task, service, registry and file creation times against the initial suspicious activity.

Which process created it?The creating process often reveals whether the action was administrative, installer-driven or suspicious.

Which account was used?Confirm whether the account had a reason to create persistence on that device.

What will execute next?Review the task action, service path, registry value or startup file to understand what runs later.

Did it connect externally?Pivot from the persistence process into network activity and remote destinations.

Has it executed already?Look for follow-on process creation, repeated task runs, service starts or payload execution.

Related Agent Foskett Academy lessons

Investigating DeviceProcessEventsUnderstand process execution, parent-child relationships and command-line evidence.

Investigating DeviceRegistryEventsReview registry changes used for persistence and configuration changes.

Investigating DeviceFileEventsHunt for startup file drops, scripts and suspicious file creation.

Hunting Playbook: LOLBinsInvestigate trusted Windows tools abused before or during persistence creation.

Hunting Playbook: PowerShell AbuseInvestigate PowerShell commands commonly used to create durable access.

Building Reusable Hunting QueriesCreate repeatable hunting workflows for persistence investigations.

Coming next

Lesson 108 — Hunting Playbook: Risky Sign-insNext, Agent Foskett returns to identity telemetry and investigates risky sign-ins, user risk, authentication anomalies and suspicious access attempts.

Why this mattersPersistence proves the investigation cannot stop at the first alert. Defenders must confirm the attacker has not left behind a way back in.

Final thought

Cleaning the first alert is not the same as removing the attacker.

Agent Foskett mindsetAlways ask what survives the reboot, the password reset and the first round of remediation.

Hunting Playbook SeriesLesson 107 continues the shift from learning KQL syntax to applying KQL in real Microsoft Defender XDR investigations.

Develop IT. Protect IT.GEMXIT PTY LTD | GEMXIT UK LTD

Hunting Playbook Persistence Mechanisms in Microsoft Defender XDR

Agent Foskett Academy Lesson 107 teaches defenders how to hunt for attacker persistence mechanisms using Microsoft Defender XDR telemetry, KQL, scheduled tasks, services, registry run keys, startup folders and WMI evidence.

Learn persistence hunting with KQL and Microsoft Defender XDR

Persistence hunting helps defenders identify scheduled tasks, service creation, registry autoruns, startup folder files and WMI activity that attackers use to maintain access after compromise.

Microsoft Defender XDR persistence investigation tutorial

This lesson explains how to use DeviceProcessEvents, DeviceRegistryEvents, DeviceFileEvents and KQL timelines to investigate attacker persistence across Microsoft Defender XDR telemetry.