ACSC Logo
© 2026 GEMXIT
GEMXIT Logo
Agent Foskett • Defender XDR • DeviceProcessEvents

The PowerShell Never Triggered An Alert

Not every suspicious action arrives with a flashing red incident banner. Sometimes Microsoft Defender records exactly what happened, but the behaviour sits quietly in the telemetry until someone asks the right question.

In this Agent Foskett briefing, we look at how suspicious PowerShell activity can hide behind normal administration, browser activity, Office documents, encoded commands and living-off-the-land behaviour. The lesson is simple: no alert does not always mean no activity.

Discuss your environment Back to briefings
Agent Foskett PowerShell threat hunting briefing
Briefing summary

PowerShell is not bad by itself. Administrators use it every day. Attackers use it for the same reason: it is powerful, trusted, scriptable and often already available.

Find PowerShell that did not alert
Review parent and child process chains
Pivot into network and persistence evidence
🚨 The alert never came. The telemetry was still there.
Defender may record suspicious process behaviour even when no incident is generated. That is why practical threat hunting matters. Good security is not just waiting for alerts. It is knowing what to look for when something feels wrong.
Book a security review →

Why PowerShell deserves attention

PowerShell is a normal administration tool, which is exactly why attackers like it. The challenge is not detecting PowerShell. The challenge is understanding when PowerShell behaviour does not belong.
It is trusted PowerShell is already present on Windows systems. That makes it useful for administrators and attractive for attackers trying to avoid bringing obvious malware into the environment.
It can be quiet Encoded commands, hidden windows, web requests and policy bypasses may not always generate a high-confidence alert. They can still be visible in DeviceProcessEvents.
Context matters PowerShell launched by an administrator during maintenance is different from PowerShell launched by Word, Excel, Outlook, Edge or a user download folder.

First hunt: suspicious PowerShell command lines

This starting query looks for PowerShell command-line indicators often associated with suspicious activity. It should be treated as triage, not a final verdict.
suspicious-powershell-command-lines.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
DeviceProcessEvents
| where Timestamp > ago(7d)
| where FileName in~ ("powershell.exe", "pwsh.exe")
| where ProcessCommandLine has_any (
    "-enc", "-encodedcommand", "FromBase64String",
    "-w hidden", "bypass", "downloadstring",
    "invoke-webrequest", "iwr", "iex"
)
| project Timestamp, DeviceName, AccountName, FileName,
          ProcessCommandLine, InitiatingProcessFileName,
          InitiatingProcessCommandLine
| order by Timestamp desc
What to review Look at the full command line, the initiating process, the account, the device, the time of day and whether the action matches normal administration.
Why it matters This is where the investigation often starts. The command line can reveal staging, download attempts, obfuscation, or attempts to bypass execution controls.
Best next pivot Take the device and timestamp into DeviceNetworkEvents, DeviceFileEvents, DeviceRegistryEvents and Defender alerts around the same window.

Second hunt: Office or browser spawning PowerShell

This is one of the most useful checks after a phishing email, suspicious attachment, browser download, fake prompt, or user-reported incident.
office-browser-to-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
  13. 13
  14. 14
DeviceProcessEvents
| where Timestamp > ago(7d)
| where FileName in~ ("powershell.exe", "pwsh.exe")
| where InitiatingProcessFileName in~ (
    "winword.exe", "excel.exe", "powerpnt.exe",
    "outlook.exe", "chrome.exe", "msedge.exe"
)
| project Timestamp, DeviceName, AccountName,
          InitiatingProcessFileName, FileName,
          ProcessCommandLine, InitiatingProcessCommandLine
| order by Timestamp desc
Used for Validating whether a user-facing application triggered script execution after a document, link, attachment or download.
What changes the risk Office spawning PowerShell is far more interesting when the command includes encoded content, a hidden window, a web request or an unusual user profile path.
Agent Foskett mindset Do not ask only “Was malware blocked?” Ask “Did a user action cause code to run, and what did that code try to do next?”

Third hunt: LOLBins and suspicious script chains

PowerShell is not the only tool attackers abuse. Rundll32, mshta, wscript, cscript, cmd and regsvr32 can also be part of living-off-the-land behaviour.
lolbins-process-chain.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
DeviceProcessEvents
| where Timestamp > ago(7d)
| where FileName in~ (
    "powershell.exe", "pwsh.exe", "cmd.exe",
    "mshta.exe", "rundll32.exe", "regsvr32.exe",
    "wscript.exe", "cscript.exe"
)
| project Timestamp, DeviceName, AccountName,
          InitiatingProcessFileName, FileName,
          ProcessCommandLine, FolderPath
| order by Timestamp desc

Fourth hunt: suspicious outbound activity after script execution

If suspicious script execution is followed by outbound traffic, the investigation becomes much more serious. This is where a quiet event can start looking like staging, payload retrieval or command-and-control.
script-process-network-pivot.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
DeviceNetworkEvents
| where Timestamp > ago(7d)
| where InitiatingProcessFileName in~ (
    "powershell.exe", "pwsh.exe", "cmd.exe",
    "mshta.exe", "rundll32.exe", "wscript.exe"
)
| project Timestamp, DeviceName, InitiatingProcessAccountName,
          InitiatingProcessFileName, InitiatingProcessCommandLine,
          RemoteIP, RemotePort, RemoteUrl
| order by Timestamp desc

What to lock down after the hunt

A good investigation should improve the environment. These are practical hardening areas to review after finding suspicious PowerShell or LOLBin behaviour.
Attack Surface Reduction Review ASR rules for Office child processes, script abuse, executable content from email/webmail and credential theft behaviours.
Tamper Protection Confirm Defender settings cannot be silently weakened. If security controls can be disabled locally, the endpoint story changes quickly.
Least privilege Standard users should not have unnecessary local admin rights. PowerShell abuse becomes more damaging when the user context has too much access.
Logging quality Make sure Defender for Endpoint onboarding, advanced hunting data and retention support real investigations before an incident happens.
Custom detections If a hunt repeatedly finds useful signals, turn it into a Defender custom detection or Sentinel analytic rule instead of relying on memory.
Response playbooks Define what happens when suspicious script execution is found: isolate device, collect timeline, check sign-ins, inspect downloads and review persistence.
No alert does not mean no investigation.
It means the next question matters: what did Defender record, and who is looking properly?
Contact GEMXIT

Final thought

The best security teams do not just wait for alerts. They understand behaviour.
At GEMXIT We use Microsoft Defender XDR, Sentinel and KQL to hunt beyond the obvious, validate weak signals and improve practical security visibility.
Agent Foskett mindset The important question is not only “Did Defender create an alert?” It is “What does the telemetry show when we go looking properly?”

Continue the investigation with the KQL Threat Hunting Guide, Microsoft Defender KQL Guide and Microsoft Security Operations.

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

GEMXIT PTY LTD  |  GEMXIT UK LTD  |  © GEMXIT 2026

PowerShell Threat Hunting in Microsoft Defender XDR

This Agent Foskett briefing explains how to use Microsoft Defender XDR and KQL to investigate suspicious PowerShell activity that may not have triggered an alert.

DeviceProcessEvents KQL for Suspicious PowerShell

Examples include encoded commands, hidden PowerShell windows, Invoke-WebRequest, IEX, policy bypasses, Office spawning PowerShell and browser-led script execution.

Defender Endpoint Hardening and KQL Investigation

GEMXIT uses Defender XDR, Sentinel and KQL to hunt weak signals, validate suspicious endpoint behaviour and improve practical Microsoft security operations.