Agent Foskett Academy • Lesson 87 • Advanced Defender XDR Investigation

Investigating Persistence Techniques in Microsoft Defender XDR.

The attacker had access.

Then they made sure they could come back.

A scheduled task appeared. A registry key changed. A service pointed somewhere strange.

Agent Foskett followed the persistence trail.

Start Lesson 87 Back to Academy

Agent Foskett Academy lesson investigating persistence techniques in Microsoft Defender XDR

Lesson overview

Learn how defenders investigate persistence techniques by correlating scheduled tasks, registry changes, services, startup activity, WMI indicators and process evidence in Microsoft Defender XDR.

Find scheduled task persistence

Review registry Run keys and services

Correlate process and file evidence

Build the persistence timeline

Why persistence matters

Persistence is how an attacker turns temporary access into repeat access. Microsoft Defender XDR helps defenders identify the changes attackers leave behind.

Persistence can look administrativeScheduled tasks, services and registry autoruns are normal Windows features, which is why attackers abuse them to blend into expected system activity.

The trigger mattersA persistence mechanism is only useful if it launches something. The target command, script or executable often reveals the attacker objective.

Timeline proves intentWhen a suspicious process creates a task, writes a file and modifies the registry, the timeline helps prove persistence rather than random activity.

The persistence investigation workflow

Agent Foskett works backwards from suspicious autoruns to the process, account and command that created them.

1. Was persistence created?Start by looking for scheduled tasks, services, registry changes and startup activity created during the incident window.

2. Which account created it?Identify the user or process context responsible for creating the persistence mechanism.

3. What launches next?Review the command, executable, script or registry value that will run when persistence triggers.

4. Was PowerShell involved?Look for encoded commands, hidden windows, download cradles or scripts used as a persistence payload.

5. Did a service appear?Check for new or modified services that point to unusual paths, scripts or temporary folders.

6. Were Run keys changed?Review registry Run and RunOnce locations for new autoruns or suspicious command lines.

7. Was WMI used?Search for WMI-related activity that could trigger commands without obvious startup entries.

8. Can the timeline be proven?Place the process, registry, service and file events in order to prove how the attacker planned to return.

Step 1 — Find scheduled task creation

Scheduled tasks are a common persistence technique because they can launch commands at logon, startup or on a recurring schedule.

DeviceProcessEvents
| where Timestamp > ago(7d)
| where ProcessCommandLine has_any ("schtasks", "Register-ScheduledTask")
| project Timestamp,
          DeviceName,
          AccountName,
          FileName,
          InitiatingProcessFileName,
          ProcessCommandLine
| order by Timestamp desc

Step 2 — Review registry Run key changes

Registry Run and RunOnce keys can launch attacker commands when a user signs in.

DeviceRegistryEvents
| where Timestamp > ago(7d)
| where RegistryKey has_any ("\Run", "\RunOnce")
| project Timestamp,
          DeviceName,
          InitiatingProcessAccountUpn,
          ActionType,
          RegistryKey,
          RegistryValueName,
          RegistryValueData,
          InitiatingProcessFileName
| order by Timestamp desc

Step 3 — Look for new or modified services

Attackers may create services that execute malware, scripts or LOLBins with elevated privileges.

DeviceProcessEvents
| where Timestamp > ago(7d)
| where ProcessCommandLine has_any ("sc create", "New-Service", "sc.exe create", "binPath")
| project Timestamp,
          DeviceName,
          AccountName,
          FileName,
          InitiatingProcessFileName,
          ProcessCommandLine
| order by Timestamp desc

Step 4 — Search for startup folder persistence

Files written into startup folders can execute when the user logs on.

DeviceFileEvents
| where Timestamp > ago(7d)
| where FolderPath has_any ("\Startup", "Start Menu\Programs\Startup")
| project Timestamp,
          DeviceName,
          InitiatingProcessAccountUpn,
          ActionType,
          FileName,
          FolderPath,
          SHA256,
          InitiatingProcessFileName
| order by Timestamp desc

Step 5 — Investigate WMI-related persistence indicators

WMI persistence can be harder to spot because commands may trigger through event subscriptions rather than obvious startup entries.

DeviceProcessEvents
| where Timestamp > ago(7d)
| where FileName in~ ("wmic.exe", "powershell.exe")
| where ProcessCommandLine has_any ("__EventFilter", "CommandLineEventConsumer", "__FilterToConsumerBinding", "ActiveScriptEventConsumer")
| project Timestamp,
          DeviceName,
          AccountName,
          FileName,
          InitiatingProcessFileName,
          ProcessCommandLine
| order by Timestamp desc

Step 6 — Correlate persistence with file creation

After identifying a persistence command, look for the referenced script, executable or payload written to disk.

DeviceProcessEvents
| where Timestamp > ago(7d)
| where ProcessCommandLine has_any ("schtasks", "sc create", "Register-ScheduledTask", "New-Service")
| join kind=leftouter (
    DeviceFileEvents
    | where Timestamp > ago(7d)
) on DeviceId
| where Timestamp1 between (Timestamp .. Timestamp + 30m)
| project PersistenceTime = Timestamp,
          FileTime = Timestamp1,
          DeviceName,
          AccountName,
          ProcessCommandLine,
          FileName1,
          FolderPath,
          SHA256
| order by PersistenceTime desc

How to read persistence evidence

Persistence evidence should explain what was created, who created it, what it launches and whether the attacker used it later.

Creation is only the first clueA new scheduled task or service is suspicious when the command, timing, account or parent process does not match normal administration.

The payload explains the riskA persistence entry that launches PowerShell, rundll32, mshta, scripts or files from temporary paths needs deeper review.

Account context mattersPersistence created by a standard user, compromised admin account or unexpected service account changes the response priority.

Use the timelinePlace task creation, file writes, registry changes and later process launches in chronological order before concluding impact.

Real-world investigation

The suspicious taskDeviceProcessEvents records schtasks.exe creating a task on a workstation shortly after credential theft activity.

The command lineThe task launches PowerShell with a hidden window and a script stored in a user profile folder.

The file evidenceDeviceFileEvents shows the script was written to disk minutes before the task was created.

The registry clueDeviceRegistryEvents shows a Run key modified on the same device by the same account.

The repeat executionLater process events show the task launching again after reboot, confirming the persistence mechanism was active.

The conclusionThe investigation confirms the attacker established persistence and the device requires containment, cleanup and account review.

Investigation checklist

Scheduled tasks checkedReview schtasks.exe, Register-ScheduledTask and task creation command lines.

Registry autoruns reviewedInspect Run and RunOnce keys for suspicious values, scripts or uncommon paths.

Services assessedLook for newly created services, unusual binPath values and unexpected service accounts.

Startup folders checkedReview files written to Startup folders and correlate them with initiating processes.

WMI activity reviewedSearch for WMI event filters, consumers and filter-to-consumer bindings.

Payload identifiedIdentify the script, executable, DLL or LOLBin launched by the persistence mechanism.

Timeline documentedDocument creation time, initiating account, payload location and later execution evidence.

Related Agent Foskett Academy lessons

Investigating Credential TheftUnderstand how stolen credentials can lead to ongoing access and post-compromise activity.

Building a Device TimelineCorrelate process, file, network and logon events into a clear device timeline.

Investigating Living Off The Land (LOLBins)Identify trusted Windows binaries abused to execute attacker commands.

Investigating PowerShell AttacksReview encoded commands, script execution and suspicious PowerShell behaviour.

Investigating Lateral MovementTrack how attackers move between devices after gaining access.

Investigating Ransomware BehaviourConnect persistence and execution evidence with later ransomware behaviour.

Coming next

Lesson 88 — Building an IOC HuntNext, Agent Foskett builds an indicator of compromise hunt to search for known hashes, IP addresses, URLs, domains and suspicious artefacts across Microsoft Defender XDR.

Why this mattersAfter persistence is confirmed, defenders often need to hunt across the environment to determine whether the same indicators appear elsewhere.

Final thought

Persistence is the attacker asking for a second chance.

Agent Foskett mindsetDo not only remove the visible payload. Find the mechanism that would have brought it back.

Prove the return pathA good persistence investigation explains how access was maintained and how that path was removed.

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

Investigating Persistence Techniques in Microsoft Defender XDR

Agent Foskett Academy Lesson 87 teaches defenders how to investigate persistence techniques in Microsoft Defender XDR.

Persistence techniques investigation workflow

This lesson explains how DeviceProcessEvents, DeviceRegistryEvents, DeviceFileEvents, scheduled tasks, registry Run keys, Windows services, startup folders, WMI activity and persistence timelines help defenders identify attacker methods used to maintain access.