Agent Foskett Academy • SOC Analyst Academy • Module 4 • Lesson 36 • Endpoint Incidents: Following the Attack Chain

Lesson 36 — The Suspicious Process Created Persistence

The attack chain had already moved quickly.

PowerShell executed. A new file appeared. The file ran. Then it contacted an external IP address.

Now another event appeared in the endpoint timeline:

a new scheduled task had been created.

That changed the investigation. The attacker might no longer be relying on the original execution path. They may have created a way to return after logoff, reboot or process termination.

Agent Foskett's next question was: what persistence mechanism was created, what launches it, and does it connect back to the suspicious process?

Persistence is not just a configuration change. It can be the point where temporary execution becomes continuing access.

Investigate Persistence Back to SOC Analyst Academy

Agent Foskett investigating endpoint persistence in Microsoft Defender XDR

The process wanted to come back

Follow scheduled-task creation, registry changes and process evidence to determine whether the suspicious executable established persistence.

✓ Hunt scheduled-task creation

✓ Investigate registry persistence

✓ Correlate changes with the process chain

✓ Determine persistence scope

Case briefing

10:14:27 powershell.exe starts ↓ 10:14:38 update-check.exe created ↓ 10:14:45 update-check.exe executes ↓ 10:14:53 external connection begins ↓ 10:15:19 SCHEDULED TASK CREATED TASK System Update Check ACTION C:\Users\alex.wilson\AppData\Local\Temp\update-check.exe THE QUESTION Was this normal software configuration? OR Did the suspicious process just create a way to execute again later?

Investigation objective

Determine what persistence mechanism was created, which process created it, what command or executable it launches and whether the change belongs to the established endpoint attack chain.

Investigator's rule

Configuration changes need ancestry too. A scheduled task or Run key becomes much more significant when its initiating process is already part of a suspicious chain.

Stage 1 — understand common persistence evidence

Mechanism	What the analyst should examine
Scheduled task	Task name, action, trigger, creator process, user context and creation time.
Registry Run / RunOnce key	Registry path, value name, configured command and initiating process.
Startup location	Created files, source process, user profile and execution target.
Service creation	Service name, binary path, account context and creator process.

Persistence mechanisms are also legitimate

Administrators, installers and business applications create scheduled tasks and startup entries every day. The mechanism itself is not the verdict.

Context changes the meaning

A newly created task becomes more concerning when it launches the same low-prevalence executable already connected to suspicious PowerShell and outbound network activity.

Stage 2 — hunt scheduled-task activity

12345 6789101112 13 14 15 16

let TargetDevice = "WS-FIN-044";
DeviceEvents
| where Timestamp > ago(24h)
| where DeviceName =~ TargetDevice
| where ActionType in (
    "ScheduledTaskCreated",
    "ScheduledTaskUpdated"
)
| project Timestamp,
          ActionType,
          DeviceName,
          AccountName,
          AdditionalFields,
          InitiatingProcessFileName,
          InitiatingProcessCommandLine
| order by Timestamp asc

Inspect AdditionalFields

Depending on the event, useful task details may be contained in AdditionalFields. Preserve the raw event and extract only fields actually present in your telemetry.

Who created the task?

The initiating process can connect the persistence event back to the suspicious executable or another process it launched.

Stage 3 — hunt registry persistence

12345 6789101112 131415 16 17

let TargetDevice = "WS-FIN-044";
DeviceRegistryEvents
| where Timestamp > ago(24h)
| where DeviceName =~ TargetDevice
| where RegistryKey has_any (
    @"\Software\Microsoft\Windows\CurrentVersion\Run",
    @"\Software\Microsoft\Windows\CurrentVersion\RunOnce"
)
| project Timestamp,
          ActionType,
          RegistryKey,
          RegistryValueName,
          RegistryValueData,
          InitiatingProcessFileName,
          InitiatingProcessCommandLine,
          AccountName
| order by Timestamp asc

Record the configured command

The registry value data may identify the executable or command that will run later. Compare it with known suspicious artifacts from the incident.

Do not search only one mechanism

An attacker can use more than one persistence technique. Scheduled tasks and Run keys are useful starting points, not an exhaustive persistence checklist.

Stage 4 — connect persistence to the attack timeline

10:14:27 powershell.exe ↓ 10:14:38 update-check.exe created ↓ 10:14:45 update-check.exe executed ↓ 10:14:53 external IP contacted ↓ 10:15:19 scheduled task created ↓ TASK ACTION update-check.exe ONE ARTIFACT NOW APPEARS IN: FILE CREATION PROCESS EXECUTION NETWORK ACTIVITY PERSISTENCE

The chain is getting stronger

Each event supports the next. The persistence finding is not being evaluated in isolation; it is being added to an already established sequence.

Precise timestamps still matter

The scheduled task appeared only seconds after the network connection. Preserve that timing so another analyst can reconstruct the sequence.

Stage 5 — find the persistence creator process

12345 6789101112 13 14 15 16

DeviceProcessEvents
| where Timestamp > ago(24h)
| where DeviceName =~ "WS-FIN-044"
| where FileName in~ (
    "update-check.exe",
    "schtasks.exe"
)
| project Timestamp,
          AccountName,
          FileName,
          ProcessCommandLine,
          SHA1,
          InitiatingProcessFileName,
          InitiatingProcessCommandLine
| order by Timestamp asc

Look for administrative utilities

Tools such as schtasks.exe are legitimate Windows utilities. Their significance comes from command-line arguments, ancestry, user context and timing.

Living-off-the-land does not mean invisible

Attackers may use trusted operating-system utilities, but process telemetry can still show who launched them and what command was supplied.

Stage 6 — search for the same persistence elsewhere

12345 67891011 12 13 14 15

DeviceEvents
| where Timestamp > ago(30d)
| where ActionType in (
    "ScheduledTaskCreated",
    "ScheduledTaskUpdated"
)
| where AdditionalFields has "System Update Check"
   or AdditionalFields has "update-check.exe"
| project Timestamp,
          DeviceName,
          AccountName,
          ActionType,
          AdditionalFields,
          InitiatingProcessFileName
| order by Timestamp desc

Scope can change the response

If the same suspicious persistence appears on multiple endpoints, the incident may require broader containment and hunting rather than remediation of one device.

Search by multiple pivots

Task names can be changed. Hunt using the executable name, hash, command line, registry value and other known indicators rather than relying on one label.

Stage 7 — test competing explanations

Hypothesis	Evidence to validate
Approved software task	Known installer, signed application, expected task name, approved deployment and historical prevalence.
Administrator-created automation	Change record, administrator account, known script and expected business purpose.
User application startup behaviour	Expected application path, vendor documentation and normal historical activity.
Malicious persistence	Suspicious creator process, unusual executable, attack-chain timing and unexplained startup mechanism.

Stage 8 — make the SOC decision

PERSISTENCE EVENT FOUND ↓ IDENTIFY MECHANISM ↓ IDENTIFY CREATOR PROCESS ↓ RECORD TASK / KEY / COMMAND ↓ CORRELATE WITH KNOWN ARTIFACT ↓ PLACE EVENT IN TIMELINE ↓ HUNT ACROSS OTHER DEVICES ↓ VALIDATE BUSINESS CONTEXT ↓ ESCALATE / CONTAIN / REMEDIATE

The persistence mechanism mattered because it launched the same executable already connected to the suspicious PowerShell, file and network chain.

Write the investigation finding

ENDPOINT INVESTIGATION FINDING At 10:15:19, endpoint telemetry recorded creation of a scheduled task named: System Update Check The task action referenced: update-check.exe The same executable had previously been: - created by suspicious PowerShell activity - executed seven seconds after creation - observed contacting an external IP The persistence event occurred less than one minute after initial execution. No approved software deployment or expected business explanation was identified. DECISION Escalate and contain the endpoint. REASON The scheduled task provides evidence that the suspicious execution chain attempted to establish continued execution on the device.

Lesson 36 key takeaways

Persistence mechanisms must be evaluated in process and timeline context.
Scheduled tasks and registry Run keys can be legitimate or malicious.
Identify the process responsible for creating the persistence mechanism.
Record the exact task action, registry value or configured command.
Correlate persistence with known suspicious files, hashes and processes.
Use precise timestamps to extend the attack timeline.
Legitimate Windows utilities can be used to create persistence.
Hunt the persistence mechanism across other endpoints.
Test approved software and administrative explanations before reaching a verdict.
Escalate when persistence forms part of a continuing evidence-backed compromise chain.

Module 4 — Endpoint Incidents: Following the Attack Chain

Lesson 36 shows the suspicious process establishing persistence. Next, Agent Foskett investigates a more serious development: an unexpected process accessing LSASS.

Next: Lesson 37 — LSASS Was Accessed by an Unexpected Process

Continue your SOC Analyst training

Module 3 focuses on identity incidents, authentication, MFA, privilege, sessions and application access.

SOC Analyst Academy KQL Academy Microsoft Sentinel Academy Defender for Endpoint Academy Microsoft Entra Security Academy Security Copilot Academy Agent Foskett Academy

🔎 SOC Analyst Academy — Module 4: Endpoint Incidents: Following the Attack Chain

Follow endpoint evidence across execution, persistence, credential access, movement and containment.

← Previous lesson

Lesson 35 — The Process Connected to an External IP Connect execution with outbound network activity.

✅ Current lesson

Lesson 36 — The Suspicious Process Created Persistence Investigate scheduled tasks, registry changes and persistence.

Next lesson →

Lesson 37 — LSASS Was Accessed by an Unexpected Process Recognise credential-access behaviour.

How to investigate persistence in Microsoft Defender XDR

Lesson 36 of the Agent Foskett SOC Analyst Academy teaches analysts how to investigate suspicious persistence using scheduled-task activity, DeviceRegistryEvents, DeviceProcessEvents and Microsoft Defender XDR endpoint telemetry.

KQL scheduled task and registry persistence hunting for SOC analysts

Learn how to correlate persistence mechanisms with suspicious processes, hunt Run and RunOnce registry changes, identify scheduled-task creation and determine whether persistence belongs to a wider endpoint compromise.