ACSC Logo
© 2026 GEMXIT
GEMXIT Logo
Agent Foskett Academy • Lesson 82 • Advanced Defender XDR Investigation

Investigating PowerShell Attacks in Microsoft Defender XDR.

PowerShell executed.

Nobody noticed.

Until the command line revealed what really happened.

Agent Foskett followed the evidence.

Start Lesson 82 Back to Academy
Agent Foskett Academy lesson investigating PowerShell attacks in Microsoft Defender XDR
Lesson overview

Learn how to investigate malicious PowerShell activity by analysing process creation, encoded commands, suspicious parent processes, downloads, network activity and file evidence.

Start with DeviceProcessEvents
Find encoded and hidden commands
Review parent processes and downloads
Build the PowerShell attack timeline

Why PowerShell attacks matter

PowerShell is legitimate administration tooling, which is exactly why attackers abuse it. The command line often tells the real story.
PowerShell is trustedAttackers abuse PowerShell because it already exists on Windows devices and is commonly used by administrators.
Commands can be hiddenEncoded commands, hidden windows and download cradles can disguise payload retrieval, discovery and execution.
Process evidence tells the storyDeviceProcessEvents records who launched PowerShell, which parent process started it and what command line was used.

The PowerShell attack investigation workflow

Agent Foskett starts with the process, then follows the command line into network, file and timeline evidence.
1. Was PowerShell executed?Start by identifying PowerShell process activity across devices.
2. Who launched it?Review the account, device and initiating process context.
3. Which parent process started it?Office, browsers, scripts or remote tools launching PowerShell need careful review.
4. Was the command encoded?EncodedCommand and short switches such as -enc can hide attacker instructions.
5. Did it download content?Look for Invoke-WebRequest, WebClient, curl, wget and DownloadString patterns.
6. Did it contact the Internet?Correlate process and network telemetry to identify outbound connections.
7. Did it create files?Review files written to disk after PowerShell executed.
8. Can the timeline be proven?Place execution, network and file evidence into one sequence.

Step 1 — Find PowerShell execution

Start with DeviceProcessEvents to identify where PowerShell executed and which account launched it.
step-1-find-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
DeviceProcessEvents
| where Timestamp > ago(24h)
| where FileName in~ ("powershell.exe", "pwsh.exe")
| project Timestamp,
          DeviceName,
          AccountName,
          AccountUpn,
          FileName,
          InitiatingProcessFileName,
          ProcessCommandLine
| order by Timestamp desc

Step 2 — Look for encoded commands

Encoded PowerShell is not automatically malicious, but it is a strong reason to investigate the full command context.
step-2-encoded-powershell.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
DeviceProcessEvents
| where Timestamp > ago(24h)
| where FileName in~ ("powershell.exe", "pwsh.exe")
| where ProcessCommandLine has_any ("-enc", "-encodedcommand", "EncodedCommand")
| project Timestamp,
          DeviceName,
          AccountName,
          InitiatingProcessFileName,
          ProcessCommandLine
| order by Timestamp desc

Step 3 — Review suspicious parent processes

PowerShell launched by Office, browsers or script hosts can indicate phishing follow-on activity or user-driven execution.
step-3-suspicious-parent-processes.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
DeviceProcessEvents
| where Timestamp > ago(24h)
| where FileName in~ ("powershell.exe", "pwsh.exe")
| where InitiatingProcessFileName in~ ("winword.exe", "excel.exe", "outlook.exe", "powerpnt.exe", "msedge.exe", "chrome.exe", "wscript.exe", "cscript.exe")
| project Timestamp,
          DeviceName,
          AccountName,
          InitiatingProcessFileName,
          InitiatingProcessCommandLine,
          ProcessCommandLine
| order by Timestamp desc

Step 4 — Find download behaviour

PowerShell download cradles often appear in command lines before payloads are written to disk or executed.
step-4-powershell-downloads.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
DeviceProcessEvents
| where Timestamp > ago(24h)
| where FileName in~ ("powershell.exe", "pwsh.exe")
| where ProcessCommandLine has_any ("Invoke-WebRequest", "iwr", "curl", "wget", "WebClient", "DownloadString", "DownloadFile")
| project Timestamp,
          DeviceName,
          AccountName,
          InitiatingProcessFileName,
          ProcessCommandLine
| order by Timestamp desc

Step 5 — Correlate PowerShell with network activity

Join PowerShell process evidence with network telemetry to identify outbound connections made after execution.
step-5-powershell-network-correlation.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
  22. 22
DeviceProcessEvents
| where Timestamp > ago(24h)
| where FileName in~ ("powershell.exe", "pwsh.exe")
| project ProcessTime = Timestamp,
          DeviceId,
          DeviceName,
          AccountName,
          ProcessCommandLine
| join kind=inner (
    DeviceNetworkEvents
    | project NetworkTime = Timestamp,
              DeviceId,
              InitiatingProcessFileName,
              RemoteUrl,
              RemoteIP,
              RemotePort
) on DeviceId
| where NetworkTime between (ProcessTime .. ProcessTime + 30m)
| where InitiatingProcessFileName in~ ("powershell.exe", "pwsh.exe")
| order by NetworkTime asc

Step 6 — Check files created after PowerShell

File creation can confirm whether PowerShell downloaded a payload, wrote a script or staged tools for later execution.
step-6-powershell-file-activity.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
  22. 22
DeviceProcessEvents
| where Timestamp > ago(24h)
| where FileName in~ ("powershell.exe", "pwsh.exe")
| project ProcessTime = Timestamp,
          DeviceId,
          DeviceName,
          AccountName,
          ProcessCommandLine
| join kind=inner (
    DeviceFileEvents
    | project FileTime = Timestamp,
              DeviceId,
              FileName,
              FolderPath,
              SHA256,
              InitiatingProcessFileName
) on DeviceId
| where FileTime between (ProcessTime .. ProcessTime + 30m)
| where InitiatingProcessFileName in~ ("powershell.exe", "pwsh.exe")
| order by FileTime asc

How to read the evidence

A PowerShell process is only the starting point. The surrounding context decides whether it is normal administration or attacker activity.
Command line firstPowerShell investigations start with the exact command line, not just the process name.
Parent process mattersPowerShell started by Word means something very different from PowerShell started by an administrator console.
Network confirms intentOutbound connections after execution may reveal payload retrieval or command-and-control behaviour.
Files close the loopNew scripts, executables, archives or hashes help confirm what the command produced.

Real-world investigation

One command line can explain the whole attack path when it is tied to parent process, network and file evidence.
The alertA workstation reports suspicious PowerShell execution shortly after a user opens a document.
The parent processDeviceProcessEvents shows winword.exe launching powershell.exe.
The command lineThe command includes an encoded payload and hidden execution flags.
The downloadPowerShell contacts an unfamiliar external domain and retrieves content.
The file evidenceDeviceFileEvents records a script and executable written shortly after the connection.
The conclusionThe investigation confirms malicious PowerShell execution and requires device containment, account review and payload hunting.

Investigation checklist

Use this checklist when reviewing suspicious PowerShell activity in Microsoft Defender XDR.
PowerShell executedConfirm the device, account, timestamp and command line.
Parent process reviewedCheck whether the initiating process was expected or suspicious.
Encoded command checkedLook for -enc, -EncodedCommand and obfuscated command patterns.
Download behaviour inspectedReview WebClient, Invoke-WebRequest, curl, wget and DownloadString usage.
Network activity correlatedIdentify RemoteUrl, RemoteIP and remote ports linked to PowerShell.
Files reviewedInspect scripts, payloads, archives and hashes created after execution.
Timeline completedDocument execution, download, file creation and any follow-on activity.

Related Agent Foskett Academy lessons

DeviceProcessEvents InvestigationsAnalyse process execution, command lines and parent-child process relationships.
DeviceNetworkEvents InvestigationsInvestigate outbound and internal network connections from Defender endpoint telemetry.
DeviceFileEvents InvestigationsReview files created, modified or downloaded during suspicious endpoint activity.
Investigating Lateral MovementFollow attackers as they move between devices using valid credentials and remote access.
Building a Complete Phishing InvestigationSee how email activity can lead into endpoint execution and follow-on investigation.
Correlating EmailEvents with DeviceProcessEventsPractise connecting phishing evidence with process execution on the endpoint.
Microsoft Defender KQL Threat Hunting GuideUse the broader GEMXIT Defender KQL guide for hunting across email, identity and endpoint data.

Coming next

Lesson 83 moves from command execution into ransomware behaviour and destructive endpoint activity.
Lesson 83 — Investigating Ransomware BehaviourNext, Agent Foskett investigates rapid file modification, suspicious encryption patterns, ransom notes and endpoint signals that indicate ransomware behaviour.
Why this mattersPowerShell is often used before larger impact. Lesson 83 follows the investigation into ransomware-style behaviour and containment decisions.

Final thought

PowerShell is not the problem by itself. The parent process, command line and follow-on behaviour decide what the evidence means.
Agent Foskett mindsetDo not stop at powershell.exe. Read the command line, follow the parent process, check the network and confirm the files.
The command line told the storyWhen the evidence is placed in order, PowerShell becomes less mysterious and the attacker behaviour becomes easier to explain.
Develop IT. Protect IT.GEMXIT PTY LTD | GEMXIT UK LTD

Investigating PowerShell Attacks in Microsoft Defender XDR

Agent Foskett Academy Lesson 82 teaches defenders how to investigate PowerShell attacks in Microsoft Defender XDR.

Defender XDR PowerShell attack investigation workflow

This lesson explains how DeviceProcessEvents, DeviceNetworkEvents, DeviceFileEvents, ProcessCommandLine, InitiatingProcessFileName, encoded commands, download cradles, RemoteUrl, RemoteIP and file hashes help defenders reconstruct malicious PowerShell activity.

ACSC Logo

GEMXIT PTY LTD  |  GEMXIT UK LTD  |  © GEMXIT 2026