ACSC Logo
© GEMXIT
GEMXIT Logo
Agent Foskett Investigation • Microsoft Defender XDR • PowerShell • Persistence • DeviceRegistryEvents • DeviceEvents • KQL

The PowerShell Process Lasted Four Seconds — The Persistence Lasted Four Weeks

PowerShell started.

Four seconds later, it was gone.

No long-running process.
No obvious malware still sitting in memory.
Nothing about the process lifetime looked persistent.

Then Agent Foskett stopped asking how long PowerShell ran.

He asked what PowerShell left behind.

Four weeks of execution history answered the question.

Discuss endpoint security Back to investigations
Agent Foskett investigating short-lived PowerShell activity that created long-term persistence
The Process Lifetime Was a Distraction

A process can exist for only seconds and still create a registry entry, scheduled task or other mechanism that continues executing long after the original process disappears.

✓ Reconstruct the original PowerShell command
✓ Hunt persistence artefacts created around it
✓ Prove how long the resulting behaviour continued

Four seconds looked insignificant

The first PowerShell event was brief. If the investigation ended with the process lifetime, it would have looked like a short execution that had already finished. Persistence investigations ask a different question: did the process create something that could survive after it exited?
Short processThe original PowerShell execution lasted only a few seconds.
No persistent PowerShell processThere was nothing continuously running to make the persistence obvious.
Historical artefacts matteredThe evidence had to be reconstructed from what happened around and after the command.

Start with the original PowerShell execution

Use DeviceProcessEvents to preserve the full command line, account, process ID and parent process around the original event. The command line is especially important because it may reveal the file, registry location, task name or script that becomes the next pivot.
original-powershell-execution.kql
  1. 1
  2. 2
  3. 3
  4. 4
  5. 5
  6. 6
  7. 7
  8. 8
  9. 9
  10. 10
  11. 11
  12. 12
  13. 13
  14. 14
  15. 15
  16. 16
  17. 17
  18. 18
  19. 19
  20. 20
let Device = "LAPTOP-042";
let StartTime = datetime(2026-07-28 10:14:00);
let EndTime = datetime(2026-07-28 10:16:00);
DeviceProcessEvents
| where Timestamp between (StartTime .. EndTime)
| where DeviceName =~ Device
| where FileName in~ ("powershell.exe", "pwsh.exe")
| project Timestamp,
          DeviceName,
          AccountName,
          FileName,
          ProcessCommandLine,
          ProcessId,
          InitiatingProcessFileName,
          InitiatingProcessCommandLine,
          SHA1
| order by Timestamp asc

Did PowerShell create a Run key?

Registry Run and RunOnce locations are common persistence points worth checking when the command or surrounding evidence suggests registry modification. Search DeviceRegistryEvents around the original execution and keep the initiating process context visible.
registry-persistence-window.kql
  1. 1
  2. 2
  3. 3
  4. 4
  5. 5
  6. 6
  7. 7
  8. 8
  9. 9
  10. 10
  11. 11
  12. 12
  13. 13
  14. 14
  15. 15
  16. 16
  17. 17
  18. 18
  19. 19
  20. 20
  21. 21
let Device = "LAPTOP-042";
let StartTime = datetime(2026-07-28 10:13:00);
let EndTime = datetime(2026-07-28 10:18:00);
DeviceRegistryEvents
| where Timestamp between (StartTime .. EndTime)
| where DeviceName =~ Device
| where RegistryKey has_any
    ("\CurrentVersion\Run",
     "\CurrentVersion\RunOnce")
| project Timestamp,
          DeviceName,
          ActionType,
          RegistryKey,
          RegistryValueName,
          RegistryValueData,
          InitiatingProcessFileName,
          InitiatingProcessCommandLine
| order by Timestamp asc

What about a scheduled task?

Persistence can also be established through scheduled-task activity. DeviceEvents can contain relevant task-related action types depending on the telemetry available in the environment. Search the original window and inspect AdditionalFields rather than assuming one fixed event shape.
scheduled-task-window.kql
  1. 1
  2. 2
  3. 3
  4. 4
  5. 5
  6. 6
  7. 7
  8. 8
  9. 9
  10. 10
  11. 11
  12. 12
  13. 13
  14. 14
  15. 15
  16. 16
  17. 17
let Device = "LAPTOP-042";
let StartTime = datetime(2026-07-28 10:13:00);
let EndTime = datetime(2026-07-28 10:18:00);
DeviceEvents
| where Timestamp between (StartTime .. EndTime)
| where DeviceName =~ Device
| where ActionType has_any ("ScheduledTask", "Task")
| project Timestamp,
          DeviceName,
          ActionType,
          InitiatingProcessFileName,
          InitiatingProcessCommandLine,
          AdditionalFields
| order by Timestamp asc

The original process disappeared — the command came back

A script or command referenced by the persistence mechanism becomes a strong historical pivot. Hunt for later executions on the same device. If the same payload or command reappears after the original PowerShell process has exited, the investigation now has evidence of recurring execution.
later-persistence-executions.kql
  1. 1
  2. 2
  3. 3
  4. 4
  5. 5
  6. 6
  7. 7
  8. 8
  9. 9
  10. 10
  11. 11
  12. 12
  13. 13
  14. 14
  15. 15
  16. 16
  17. 17
let Device = "LAPTOP-042";
let PersistenceCommand = "update.ps1";
DeviceProcessEvents
| where Timestamp > ago(30d)
| where DeviceName =~ Device
| where ProcessCommandLine has PersistenceCommand
| project Timestamp,
          DeviceName,
          AccountName,
          FileName,
          ProcessCommandLine,
          InitiatingProcessFileName,
          InitiatingProcessCommandLine
| order by Timestamp asc

The timeline stretched from seconds to weeks

Summarise the recurring execution to establish the first and last observed timestamps. This is where a four-second process can become a four-week incident: the original execution may have been brief, while the artefact it created repeatedly relaunched activity.
persistence-duration.kql
  1. 1
  2. 2
  3. 3
  4. 4
  5. 5
  6. 6
  7. 7
  8. 8
  9. 9
  10. 10
  11. 11
  12. 12
  13. 13
  14. 14
  15. 15
  16. 16
let Device = "LAPTOP-042";
let PersistenceCommand = "update.ps1";
DeviceProcessEvents
| where Timestamp > ago(30d)
| where DeviceName =~ Device
| where ProcessCommandLine has PersistenceCommand
| summarize Executions=count(),
            FirstSeen=min(Timestamp),
            LastSeen=max(Timestamp),
            Parents=make_set(InitiatingProcessFileName, 20)
    by DeviceName,
       AccountName,
       ProcessCommandLine

Did the same persistence appear on other devices?

Once the persistence command or script is understood, scope it across the environment. A mechanism found on one endpoint may have been deployed elsewhere, turning a local persistence investigation into a broader incident.
cross-device-persistence-scope.kql
  1. 1
  2. 2
  3. 3
  4. 4
  5. 5
  6. 6
  7. 7
  8. 8
  9. 9
  10. 10
  11. 11
  12. 12
  13. 13
let PersistenceCommand = "update.ps1";
DeviceProcessEvents
| where Timestamp > ago(30d)
| where ProcessCommandLine has PersistenceCommand
| summarize Executions=count(),
            FirstSeen=min(Timestamp),
            LastSeen=max(Timestamp),
            Accounts=make_set(AccountName, 20)
    by DeviceName
| order by FirstSeen asc

The process and the persistence were different evidence

The original PowerShell process explains how the persistence may have been established. Registry, task and later process telemetry explain what survived. Keeping those evidence types separate prevents the investigation from treating one short-lived process as the entire incident.
Initial executionShows what PowerShell was instructed to do.
Persistence artefactShows the mechanism capable of surviving after PowerShell exited.
Recurring executionShows whether the persistence actually continued to trigger activity.

What the evidence can and cannot prove

A Run key, scheduled task or recurring script execution can provide strong persistence evidence when the timestamps and initiating context align. A persistence location alone is not automatically malicious: legitimate software uses many of the same mechanisms. The command, creator, path, signer, timing and subsequent behaviour determine the verdict.
ProvenTelemetry can establish that the artefact was created and that related commands executed later.
CorrelatedTiming and initiating-process context can connect the short PowerShell event to the persistence mechanism.
Do not overclaimScheduled tasks and Run keys are not inherently malicious.

Agent Foskett's investigation mindset

Do not measure an incident by how long the first suspicious process remained alive. Measure what changed because that process ran. A four-second command can create an artefact that survives reboots, user logons and weeks of normal activity.
Follow what changedLook for registry, task, file and configuration activity around the original process.
Follow what returnedSearch for later executions of the command or payload.
Follow the full durationUse first-seen and last-seen evidence to establish the real incident timeline.

Investigation findings

The original PowerShell process was short-lived, but telemetry around that execution exposed a persistence mechanism that continued to relaunch related activity. Historical process events showed recurring execution across the following weeks. The process lifetime therefore described only the installer stage of the incident, not the lifetime of the persistence it established.
PowerShell lasted secondsThe initial process itself disappeared almost immediately.
Persistence survivedA mechanism created around the original event continued to trigger execution.
The incident lasted weeksHistorical telemetry revealed the true duration of the activity.

Related Agent Foskett investigations

Continue with PowerShell, persistence and endpoint investigations.
The Command Line Told a Different StoryInvestigate what process arguments reveal beyond the executable name. The Registry Key Survived the RebootFollow registry persistence and determine what continued after the original execution. Agent Foskett AcademyBuild practical Microsoft security investigation and KQL skills.
The process lasted four seconds. The persistence lasted four weeks.
Investigate what the process changed, not only how long it remained alive.
Continue the Investigation

Final thought

Process duration is easy to see and easy to misunderstand. The dangerous part of a short command may be the registry value it writes, the task it creates or the script it arranges to run later. When a suspicious process lasts only seconds, the investigation should not become shorter. Sometimes that is exactly when you need to look weeks further into the timeline.
What did it create?Search the original execution window for persistence artefacts.
What ran later?Use the resulting command or payload as a historical pivot.
How long did it really survive?Measure the persistence timeline rather than the first process lifetime.
Develop IT. Protect IT.
GEMXIT PTY LTD | GEMXIT UK LTD
Talk to GEMXIT
ACSC Logo

GEMXIT PTY LTD  |  GEMXIT UK LTD  |  © GEMXIT

The PowerShell Process Lasted Four Seconds — The Persistence Lasted Four Weeks

This Agent Foskett investigation explores short-lived PowerShell execution, endpoint persistence, DeviceProcessEvents, DeviceRegistryEvents, DeviceEvents and KQL in Microsoft Defender XDR.

PowerShell Persistence Investigation

The investigation follows a brief PowerShell process into registry and scheduled-task evidence, then hunts later executions to establish how long the persistence survived.

Microsoft Defender XDR Persistence Hunting And KQL

Process lifetime does not define incident lifetime. Historical endpoint telemetry helps defenders connect an initial command to persistence mechanisms and recurring execution.