Hunting Suspicious PowerShell: Look Past the Process Name

PowerShell runs legitimately across most Windows estates. Alerting every time powershell.exe starts produces noise; treating the absence of that filename as safety creates a blind spot.

Attackers can execute PowerShell through alternate hosts or load System.Management.Automation into another process. Even when the standard executable appears, the useful evidence is rarely the name alone.

Obfuscation is a clue, not a verdict. Common patterns include encoded commands, fragmented strings, execution-policy bypasses, hidden windows, and download-and-execute primitives.

• -EncodedCommand, shortened variants, or calls to FromBase64String.
• Combinations such as Bypass, NoProfile, NonInteractive, and WindowStyle Hidden.
• String construction intended to hide Invoke-Expression or other sensitive terms.
• Invoke-WebRequest, Net.WebClient, or Start-BitsTransfer followed by execution.

title: Suspicious PowerShell Encoding or Download Primitives
logsource:
  category: process_creation
  product: windows
detection:
  image:
    Image|endswith:
      - '\powershell.exe'
      - '\pwsh.exe'
  content:
    CommandLine|contains:
      - '-EncodedCommand'
      - 'FromBase64String'
      - 'DownloadString'
      - 'Invoke-WebRequest'
  condition: image and content
level: high

Keyword rules catch low-effort activity, but they are easy to evade. Script Block Logging records processed script-block content and produces Event ID 4104, giving defenders visibility beyond the original command line.

Process ancestry supplies the execution story. A familiar PowerShell command launched by a trusted management agent has different meaning from the same command launched through a document, browser, or script host.

Go beyond the immediate parent. A chain such as browser → script host → command shell → PowerShell often explains intent more clearly than any single process.

PowerShell often acts as a download, discovery, or launch stage. Network telemetry can reveal what happened after execution: a raw-IP connection, a first-seen domain, repeated beacon-like intervals, or a download primitive paired with an actual connection.

let PowerShellProcesses = DeviceProcessEvents
| where FileName in~ ("powershell.exe", "pwsh.exe")
| where isnotempty(ProcessUniqueId)
| project DeviceId, ProcessUniqueId, ProcessCommandLine,
          ProcessStart = Timestamp;
DeviceNetworkEvents
| where InitiatingProcessFileName in~ ("powershell.exe", "pwsh.exe")
| where RemoteIPType == "Public"
| join kind=inner PowerShellProcesses on DeviceId
| where InitiatingProcessUniqueId == ProcessUniqueId
| project Timestamp, DeviceName, RemoteIP, RemoteUrl,
          RemotePort, ProcessCommandLine, ProcessStart

Use stable process-instance identifiers where available. Windows reuses process IDs, so joining only on device and PID can accidentally combine unrelated activity from different times.

• Compare the destination with domain age, reputation, hosting provider, and prevalence in your environment.
• Confirm whether the connection occurred within the lifetime of the process and whether a child process continued the activity.
• Review DNS, proxy, firewall, and endpoint telemetry together; a missing event in one source is not proof that no connection occurred.
• Validate whether the same script, signer, management tool, or destination is common across similar devices.

Encoded content, a hidden window, or an outbound HTTPS connection may each be legitimate in isolation. The useful signal is the combination and the degree to which it departs from the host, user, and management baseline.

Treat the weights as a design example, not a universal threshold. Test them against known-good administration, tune by device role, and promote combinations that consistently separate malicious behaviour from routine automation.