How do you monitor PowerShell execution on Windows?

What telemetry gives you the clearest view of PowerShell activity?

The most useful view comes from combining script block logging, module logging, and process creation telemetry. Script block logging shows what PowerShell actually executed, while process telemetry shows how it was launched, with what arguments, and from which parent process. Module logging fills in imported modules and can expose suspicious administrative or lateral-movement activity that a single event stream would miss.

That combination matters because PowerShell abuse often hides in plain sight: encoded commands, downloaded content, reflective or in-memory execution, and parent-child process chains that look normal until you compare them with the host’s usual role. On servers and admin workstations, the signal is often not one malicious line, but a pattern that stands out against expected automation.

For practical monitoring, the PowerShell Security Guide is the right internal reference for the logging controls and abuse patterns that typically matter most.

Which behaviors are most suspicious in PowerShell logs?

Focus first on long, obfuscated, or encoded command lines, especially when they include download-and-execute behavior, hidden windows, bypass flags, or references to external content. Also watch for unusual parent processes such as Office applications, script hosts, browsers, archive utilities, or living-off-the-land binaries that rarely need to start PowerShell in that environment.

Execution context is just as important as the command itself. Administrative activity on endpoints that normally do not use PowerShell, or on systems where change windows are tightly controlled, should be treated as higher value than isolated noisy events. In-memory execution and staged scripts are particularly important because they may leave little on disk, so the command line and script block content become the primary evidence.

If you also need a threat-hunting frame for what PowerShell abuse looks like after initial access, MITRE ATT&CK Enterprise Matrix is a strong external map for techniques such as execution, privilege escalation, and defense evasion.

How do you turn PowerShell monitoring into an operational control?

Monitoring is only useful if you have a baseline for approved automation, service accounts, and management workflows. Separate expected administrative use from everything else, then investigate deviations in command style, execution path, host role, and time of day. Long command strings and encoded content should be searchable, but they should also be correlated with user identity, endpoint type, and whether the activity fits a known deployment or remediation process.

Logging gaps deserve attention because adversaries often look for the easiest blind spot. If one of the three main telemetry sources is missing, your confidence drops sharply, especially when you are trying to reconstruct whether a command was typed interactively, launched by a tool, or delivered through another process. Correlating those sources gives you a better chance of distinguishing routine administration from suspicious use.

For baseline policy and hardening alignment, NIST SP 800-53 Rev 5 Security and Privacy Controls is the most relevant control catalogue for audit logging, process monitoring, and access control expectations.

Risk and Threat Considerations

PowerShell is attractive to attackers because it is native, flexible, and often trusted by defenders and administrators. The main risk is not simply that PowerShell runs, but that malicious activity can blend into legitimate administration, especially when logging is incomplete or when script content is compressed, encoded, or executed in memory.

Failure mechanism: Attackers abuse a legitimate management tool to run hidden commands, download payloads, or stage post-exploitation activity while making the process chain look routine or making the useful content harder to capture in logs.

Impact: The result can be missed detection, delayed containment, and a much harder investigation because the original command, its parent process, and its execution context are incomplete or ambiguous.

Practitioner Guidance

What to verify: Confirm that script block, module, and process creation logging are enabled where PowerShell is allowed to run, and check that the logs are arriving in your SIEM with enough retention to support investigations. If you cannot correlate command line, parent process, and script content, treat the monitoring gap as a control weakness rather than an instrumentation issue.

Decision rule: If PowerShell is executed on a host that rarely needs it, or if the command is encoded, obfuscated, or launched from an unusual parent process, escalate it for review even if no malware signature fires. If the activity matches a known automation pattern, keep it under watch but validate it against the expected change window and service ownership.

Practitioner takeaway: Good PowerShell monitoring is less about volume and more about correlation, use the telemetry mix to prove whether execution was expected, attributable, and consistent with the host’s normal administrative profile.

Related resources from NHI Mgmt Group

• How do you patch or mitigate CVE-2020-1350 (Microsoft Windows DNS Server Remote Code Execution)?
• How do you patch or mitigate CVE-2008-0015 (Microsoft Windows Video ActiveX Control Remote Code Execution)?
• How do you patch or mitigate CVE-2024-43572 (Microsoft Windows Management Console Remote Code Execution)?
• How do you patch or mitigate CVE-2022-21971 (Microsoft Windows Runtime Remote Code Execution)?