Quick wins for a faster PC:
Fix the driver behind crashes, sound loss and screen glitchesFind Drivers →Repair Windows errors before they cause bigger problemsFix Now →Scan for outdated or missing drivers - takes under a minuteDriver Scan →Script block logging records the PowerShell code an engine processes; it does not decide whether that code is malicious. To detect suspicious use, collect the right events, learn what is normal for each host and user, then investigate departures alongside process, module, and other security telemetry.
What script block logging shows—and what it does not
Microsoft describes the feature plainly: “When you enable Script Block Logging, PowerShell records the content of all script blocks that it processes.” (Microsoft Learn: about_Logging) On Windows PowerShell, these records use event ID 4104 in Microsoft-Windows-PowerShell/Operational. PowerShell 7 on Windows writes corresponding 4104 events to PowerShellCore/Operational. The engine and channel matter: collecting one does not ensure visibility into the other. (Microsoft Learn: about_Logging_Windows)
Event 4104 is evidence of processed script content, not a verdict. A legitimate administrator can run obfuscated code during incident response; an attacker can use ordinary-looking scripts. Treat unusual content as a lead and evaluate it in context.
Enable logging for the PowerShell engines in scope
Enabling Script Block Logging affects new sessions; it is not retroactive. Windows PowerShell policy can cover interactive and automated commands. PowerShell 7 has its own configuration path, so first identify which engine versions and providers are installed and used on the endpoints you intend to monitor. (Microsoft Learn: about_Logging; Microsoft Learn: about_Logging_Windows)
#1 Best Overall
- Windows PowerShell: Microsoft documents enabling Script Block Logging through Group Policy or the corresponding policy registry setting. The WindowsPowerShell Policy CSP identifies computer and user configuration scopes; computer configuration takes precedence when both apply. (Microsoft Learn: Policy CSP – WindowsPowerShell)
- PowerShell 7 on Windows: Use its documented Group Policy or
powershell.config.jsonconfiguration, and collect fromPowerShellCore/Operational. Do not assume a Windows PowerShell setting enables logging for PowerShell 7. (Microsoft Learn: about_Logging_Windows)
Invocation logging is a separate option, not a substitute for script block logging. It can produce substantially more data, so assess ingestion and retention capacity before enabling it broadly. (Microsoft Learn: about_Logging)
Protect the sensitive content in the logs
Script text can contain credentials or other sensitive data. Restrict access to the event channels and any forwarded or stored copies, and set retention according to your investigation and privacy requirements. For use beyond diagnostics, Microsoft recommends Protected Event Logging. Its model uses a public encryption certificate on endpoints while the corresponding private key is retained for decryption elsewhere; do not deploy the decryption key to the logging endpoints. Plan key custody and access before enabling collection. (Microsoft Learn: about_Logging; Microsoft Learn: about_Logging_Windows)
Rank #2
Build a baseline that reflects how PowerShell is used
A useful baseline is not one organization-wide list of allowed scripts. Compare like with like: similar host roles, accounts, parent applications, administrative tasks, module activity, and time windows. Separate groups that behave differently, such as servers managed by automation and interactive administrator workstations.
Observe representative business cycles before treating behavior as normal. Scheduled jobs, patching, onboarding, and incident response can all shift activity. Capture recurring automation identities, management tools, parent processes, common script paths or block patterns, loaded modules, and maintenance windows. Sentinel’s anomaly guidance describes baselines in terms of an entity’s history, its peers, and organization-wide patterns. (Microsoft Learn: Anomalies detected by the Microsoft Sentinel machine learning engine)
What’s actually slowing this PC down?
Pick the symptom - the matching free tool is one click away.
Detect deviations by combining signals
Prioritize combinations rather than single clues. MITRE ATT&CK’s PowerShell detection strategy identifies relevant PowerShell events 4103–4106 and 400/403, and recommends correlation with Sysmon process-creation and module-load telemetry. (MITRE ATT&CK: Abuse of PowerShell for Arbitrary Execution, DET0455)
- Encoded or obfuscated script content paired with an unexpected parent process.
- A familiar administrative script launched under an unusual account or outside its normal time window.
- A rare module load alongside suspicious process activity or network connections.
- New script behavior on a host that normally runs a narrow, stable set of automation.
Encoded arguments, unfamiliar parents, rare modules, or unusual timing merit review, but none alone proves compromise. Script-block length can help tune filters, but length is not an indicator of maliciousness by itself. MITRE describes mutable detection filters such as parent process, time window, loaded-module list, and script-block length threshold; tune them to reduce noise without treating a threshold as a security boundary. (MITRE ATT&CK: DET0455)
Choose where to analyze the events
| Approach | Useful for | Trade-off |
|---|---|---|
| Local event-log review | Checking whether logging is enabled and inspecting activity on a specific endpoint. | Each engine’s channel must be reviewed; local inspection alone does not provide a fleet-wide baseline. |
| Centralized collection and hunting | Comparing events across hosts and accounts, correlating process and module telemetry, and investigating trends. | Requires correct provider/channel coverage, sufficient retention, access controls, and rules or queries built for the collected data. |
Microsoft Sentinel offers entity baselines and machine-learning anomaly rule templates, plus hunting queries and workflows that can turn findings into analytics rules or incidents. Its general anomaly documentation does not establish that a PowerShell-specific 4104 detector is enabled automatically. A deployment should identify the data sources, rule, and configured baseline it actually uses. (Microsoft Learn: Sentinel anomalies; Microsoft Learn: Hunting capabilities in Microsoft Sentinel)
Independent reader supportYour contribution helps us test, update, and keep practical guides available for everyone.Use AMSI as complementary inspection
On Windows 10 and later, PowerShell 5.1 passes script blocks to the Antimalware Scan Interface (AMSI). PowerShell 7.3 adds .NET method invocations to the inspection data. AMSI supports inspection by antimalware products; it is not a replacement for retaining and analyzing event 4104 and related telemetry. (Microsoft Learn: PowerShell security features)
Quick Recap
Best Value
Operational checklist
- Inventory Windows PowerShell and PowerShell 7 usage, then confirm the provider and channel for each engine.
- Enable the relevant Script Block Logging policy or PowerShell 7 configuration, and validate event 4104 appears in a new session.
- Forward the correct channels and correlate them with process-creation, engine, and module-load events.
- Protect event content with restricted access, deliberate retention, and Protected Event Logging where appropriate.
- Build role-aware baselines over representative cycles; review combined deviations with an analyst before labeling activity malicious.
Product prices and availability are accurate as of the date/time indicated and are subject to change. Any price and availability information displayed on Amazon at the time of purchase will apply.
