Full Report
Joff Thyer // It is no secret that PowerShell is increasingly being used as an offensive tool for attack purposes by both Red Teamers and Criminals alike. Thanks to […] The post PowerShell Logging for the Blue Team appeared first on Black Hills Information Security, Inc..
Analysis Summary
# Best Practices: Enhancing PowerShell Security and Visibility
## Overview
These practices primarily address the security gap created by the increasing use of native PowerShell as an offensive tool (e.g., via tools like PowerSploit, Empire). The focus is on enabling robust logging capabilities, particularly on legacy systems (Windows 7), to ensure defenders can track command execution, script content, and potential obfuscated activity.
## Key Recommendations
### Immediate Actions
1. **Prioritize WMF 5.0 Deployment:** Upgrade all workstations currently running Windows 7 to use the Windows Management Framework (WMF) version 5.0 or later.
2. **Enable Minimum Logging:** Immediately enable **Script Block Logging** on all endpoints. This is crucial for capturing the de-obfuscated contents of executed code (Event ID 4104).
3. **Ensure Log Collection:** Begin planning or implementing a Security Information and Event Management (SIEM) solution capable of centrally collecting and analyzing PowerShell Operational logs.
### Short-term Improvements (1-3 months)
1. **Enable Module Logging:** Activate PowerShell Module Logging (available since PS 3.0) to record pipeline execution details, including variable initialization and command invocation (Event ID 4103).
2. **Configure Full Transcription:** Enable **Full Transcription Logging** to capture a full input/output record of every PowerShell session.
3. **Secure Transcription Storage:** Configure Transcription Logging to write session files to a secure, centralized network share rather than the default local user profile (\Documents folder) to prevent attacker tampering or deletion.
### Long-term Strategy (3+ months)
1. **Dependency Management:** Ensure all Windows 7 systems meet the prerequisite of having .NET Framework version 4.5 installed to successfully install WMF 5.0.
2. **Standardize PowerShell Version:** Establish a policy requiring a minimum PowerShell version (preferably 5.0 or higher) across the entire enterprise environment to ensure consistent security features.
3. **SIEM Rule Development:** Develop detection rules within the central logging platform specifically targeting high-value events like PowerShell Event ID 4104, paying close attention to entries logged at the "Warning" level (indicating potentially suspicious commands).
## Implementation Guidance
### For Small Organizations
- Focus resources on enforcing WMF 5.0 deployment via local group policy or endpoint management tools on all Windows 7 machines first.
- Start with enabling **Script Block Logging** and **Module Logging**.
- If a full SIEM is cost-prohibitive, ensure critical Event Logs (especially Event ID 4104) are regularly backed up or exported for manual review periodically.
### For Medium Organizations
- Utilize Active Directory Group Policy Objects (GPOs) to centrally deploy WMF 5.0 updates across OUs.
- Configure **Group Policy** to enforce PowerShell logging settings (Module, Script Block, Transcription).
- Begin testing log ingestion into the existing centralized logging infrastructure.
### For Large Enterprises
- Create phased deployment plans for WMF 5.0 upgrades, starting with pilot groups, ensuring administrative templates are deployed to the SYSVOL/Policy Definitions store for distribution.
- Configure GPOs for logging under: **Policies -> Administrative Templates -> Windows PowerShell** (in both Computer and User Configuration areas).
- Integrate the Windows PowerShell Operational log events into high-fidelity security monitoring pipelines, leveraging alerts based on suspicious command signatures identified in the logs.
## Configuration Examples
PowerShell logging features (Module Logging, Script Block Logging, Transcription) are primarily configured via Group Policy using the WMF 5.0 administrative templates.
**Key Event IDs to Monitor:**
* **4103:** Module Logging Events
* **4104:** Script Block Logging Events (Captures decoded script execution)
* **4105/4106:** Script Block Execution Start/Stop (Optional, generates high volume, suggested to be disabled initially)
**Transcription File Naming:** The system uses a naming convention that prevents collisions, but users must configure the secure output directory via GPO.
## Compliance Alignment
This effort directly supports security monitoring requirements commonly found in:
* **NIST SP 800-53 (AC-2, AU-2, AU-6):** Audit Logging, Configuration Management, and System Monitoring.
* **ISO/IEC 27001 (A.12.4):** Operations security and logging.
* **CIS Controls (Control 10: Auditing and Monitoring):** Implementing detailed logging of system activity.
## Common Pitfalls to Avoid
1. **Ignoring Windows 7:** Assuming WMF 5.0 is present on all endpoints. Windows 7 defaults to PowerShell 2.0, which lacks necessary logging. **Upgrade is mandatory.**
2. **Incomplete Template Deployment:** Installing the WMF Administrative Template files only locally, rather than copying the `.admx` and `.adml` files to the central `Policy Definitions` store for domain-wide GPO use.
3. **Leaving Transcription Logs Local:** Storing transcription files in the default user Documents folder, allowing attackers to easily delete or modify them locally before forensics occurs.
4. **Ignoring Decoded Scripts:** Relying only on basic command auditing; Script Block Logging (Event ID 4104) is required to see the content of obfuscated or Base64 encoded attacks.
## Resources
- Microsoft Windows Management Framework (WMF) download page (Ensure users search for the latest stable WMF release if the link provided in the source material is outdated, as this requires the correct administrative templates.)
- Microsoft documentation regarding PowerShell Logging Event IDs (4103, 4104).
- Security tools leveraging PowerShell analysis (e.g., PowerShell monitoring integrations within major SIEM platforms).