Listen to this Post
Introduction:
In the cat-and-mouse game of modern cybersecurity, attackers are increasingly shifting away from deploying custom, easily-detectable malware. Instead, they are weaponizing the very tools that system administrators rely on daily to manage and secure their environments. PowerShell, a powerful scripting language and command-line shell built into every modern Windows operating system, has become a prime target for this “living-off-the-land” strategy, allowing adversaries to execute commands, move laterally, and exfiltrate data using legitimate system functions. To counter this, defenders must move beyond basic antivirus and implement a robust, multi-layered PowerShell logging strategy that transforms this potential vulnerability into a rich source of telemetry for detecting and investigating attacks.
Learning Objectives:
- Understand the critical role of PowerShell in the attack chain and why it’s a favored tool for adversaries.
- Learn how to implement and configure advanced PowerShell logging features, including Module, Script Block, and Transcription logging.
- Identify key Windows Event IDs (4104, 4103, 4688, 7045) that are vital for detecting malicious activity.
- Discover how to integrate and analyze PowerShell logs with a SIEM (like Wazuh, Sentinel, or Splunk) for effective threat hunting and incident response.
- Develop practical skills to detect common attack techniques like Base64-encoded payloads, privilege escalation, and lateral movement.
1. Enabling the Trifecta of PowerShell Logging
A comprehensive PowerShell logging strategy is built on three foundational pillars: Module Logging, Script Block Logging, and Transcription. Each provides a unique perspective on PowerShell activity, and together they offer a near-complete picture of what is happening within the shell. Without these enabled, you are essentially flying blind against half of the modern attack surface. Your SIEM is only as good as the data it receives; if you don’t collect these logs, you cannot detect the attacks that use them.
Step‑by‑step guide explaining what this does and how to use it:
- Configure PowerShell Module Logging (Event ID 4103): This logs the execution of specific PowerShell modules, revealing which tools and capabilities an attacker might be using, such as `ActiveDirectory` for reconnaissance or `Invoke-Obfuscation` for evasion. You can enable this via Group Policy (Computer Configuration > Administrative Templates > Windows Components > Windows PowerShell > Turn on Module Logging) or by setting the registry key `HKEY_LOCAL_MACHINE\SOFTWARE\Policies\Microsoft\Windows\PowerShell\ModuleLogging` and adding the desired module names.
-
Enable PowerShell Script Block Logging (Event ID 4104): This is arguably the most critical component. It logs the full, raw text of the PowerShell code that is executed. Even if an attacker uses heavy obfuscation, Script Block Logging will capture the de-obfuscated code, giving you clear insight into their commands. This is also enabled via Group Policy (Turn on PowerShell Script Block Logging) or the registry key
HKEY_LOCAL_MACHINE\SOFTWARE\Policies\Microsoft\Windows\PowerShell\ScriptBlockLogging. -
Activate PowerShell Transcription (Event ID 4104): While Script Block Logging captures code, Transcription captures the entire PowerShell session, including all input and output to the console. This is invaluable for post-incident forensics, allowing investigators to replay an attacker’s actions. It can be enabled via Group Policy (Turn on PowerShell Transcription) by specifying a shared folder or a local directory for the transcript files. To set this via Windows Registry, navigate to `HKLM\SOFTWARE\Policies\Microsoft\Windows\PowerShell\Transcription` and add the `EnableTranscripting` DWORD with a value of
1. -
The Critical Event IDs Your Blue Team Must Monitor
Blue Teams need to move beyond simple alerts and build a “hunter’s mindset.” This begins by understanding the specific Windows Event IDs that serve as breadcrumbs during an investigation. Focusing on these key events allows you to filter out the noise and zero in on the malicious activity. By creating custom queries and dashboards for these IDs in your SIEM, you can proactively hunt for threats rather than just reacting to alerts.
Step‑by‑step guide explaining what this does and how to use it:
- Event ID 4103 – Module and Pipeline Execution Details: This event is triggered when a PowerShell module is loaded or when a command is executed. It provides the full command line, the user context, and the module name. To monitor this in a SIEM like Wazuh, create a rule that triggers when a high-risk module like `System.DirectoryServices` (used for AD enumeration) is used by a non-admin user. For Splunk, a search query would be
EventCode=4103 "System.DirectoryServices". -
Event ID 4104 – Script Block Logging (Executed PowerShell Commands): This is the gold mine. Search for common obfuscation patterns like `-e` or `-enc` followed by a Base64 string, or the use of `IEX` (Invoke-Expression) and
-WindowStyle Hidden. A simple grep command on a log file could be:grep -E "4104.(IEX|-enc|-e|Base64)" powershell.log. In a SIEM, you can write a rule to flag any Script Block that contains a Base64-encoded string over a certain length. -
Event ID 4688 – Process Creation Events: This event is crucial for tracking lateral movement. An attacker might use PowerShell to spawn a new process like `cmd.exe` or `powershell.exe` on a remote system. With this log enabled, you can chain together a 4688 event where the `Creator Process` is `powershell.exe` and the `Process Name` is `cmd.exe` on a server, which is a classic sign of remote execution. Enable this via the registry key
HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\CurrentVersion\Policies\System\Audit\ProcessCreation. -
Event ID 7045 – New Service Installation: Attackers frequently use PowerShell to install or modify services to maintain persistence. If you see a new service installed with an obfuscated or encoded PowerShell command as its execution path, you have a high-fidelity indicator of compromise. To analyze this, use a command like `Get-WinEvent -FilterHashtable @{LogName=’System’; ID=7045} | Where-Object {$_.Message -match “powershell” -or $_.Message -match “-enc”}` in PowerShell.
-
Decoding the Attack Patterns: What to Hunt For
The true power of logging is not just in collecting data but in knowing what to look for within it. Attackers use a predictable set of techniques that, when combined with robust logging, act like beacons. By establishing baselines for normal administrative activity, you can quickly identify and respond to anomalies. Threat hunting is about actively seeking out the hidden signs of compromise that automated alerts might miss.
Step‑by‑step guide explaining what this does and how to use it:
- Base64-Encoded Payloads: A primary indicator of an attack is the use of the `-EncodedCommand` parameter. Monitor Event ID 4104 for the `-e` or `-enc` flags. For example, a command like `powershell -e JAB7AGUAbgB2ADoAdQBzAGUAcgBuAGEAbQBlAH0A` is suspicious. Your SIEM can be configured to fire an alert when it detects this pattern, even if the payload is obfuscated.
-
Privilege Escalation and Persistence: Look for PowerShell commands that modify user permissions or create scheduled tasks. A common technique is `New-ScheduledTaskAction` and
Register-ScheduledTask. In Event ID 4103, you’ll see the specific module being used. A Linux server sending logs to a central syslog server might see a command likeschtasks /create /tn "WindowsUpdate" /tr "powershell -windowstyle hidden ...", which is a clear sign of persistence. -
Active Directory Reconnaissance: Attackers often use PowerShell to map out an environment. Commands like
Get-ADUser,Get-ADGroup,Get-ADComputer, and `Get-ADDomain` will generate Event ID 4103 and, more specifically, module logging forActiveDirectory. A spike in these commands from a non-IT workstation is a major red flag. You can create a custom detection rule in Wazuh to alert on any use of the `ActiveDirectory` module from a suspicious source IP. -
Integrating with a SIEM and Creating Custom Alerts
Collecting logs is pointless without a way to analyze them at scale. A Security Information and Event Management (SIEM) system like Wazuh, Microsoft Sentinel, or Splunk is the engine that turns raw logs into actionable intelligence. Integration is not just about forwarding events; it’s about enriching them, correlating them, and building context to distinguish real threats from false positives.
Step‑by‑step guide explaining what this does and how to use it:
- Forward Windows Events to Wazuh: On your Windows endpoints, configure the Wazuh agent to forward specific event IDs. In the `ossec.conf` file, add a `
` block for the Microsoft-Windows-PowerShell/Operational log and the Security log. Ensure the agent is set to `eventchannel` mode to read the full, rich event data. -
Create a Custom Detection Rule in Wazuh: To detect Base64-encoded PowerShell commands, create a custom rule in the `local_rules.xml` file. The rule can look for Event ID 4104 and use a regular expression to find the `-enc` parameter. For example:
`
(?i)-enc|-[bash]ncodedCommand
Detected Base64-encoded PowerShell command.
`
- Build a Threat Hunting Dashboard in Splunk: In Splunk, create a dashboard with panels for Event IDs 4104, 4103, 4688, and 7045. Use a query like `index=windows EventCode=4104 | stats count by user, host, scriptBlockText | sort – count` to start your hunt. Add a table to show new service installations (
EventCode=7045) that include `powershell.exe` in the command line.
5. Analysis of Key Attack Techniques and Mitigations
Understanding the “how” of an attack is just as important as the “what.” By analyzing the typical sequence of events in a PowerShell-based intrusion, we can build stronger defensive strategies. This involves a deep dive into lateral movement, credential theft, and data exfiltration techniques.
Step‑by‑step guide explaining what this does and how to use it:
- Lateral Movement with PowerShell Remoting: Attackers often use `Invoke-Command` or `Enter-PSSession` to run code on remote systems. This activity is logged in Event ID 4104 on the target machine. To detect this, look for the `PSSession` or `New-PSSession` cmdlets. A mitigation strategy is to restrict which users can use PowerShell Remoting and to enable Just Enough Administration (JEA) to limit what those users can do.
-
Credential Dumping and Theft: Tools like `Invoke-Mimikatz` can be run via PowerShell. While the command itself is often logged, the shellcode injection into LSASS is a process-level event. Here, Event ID 4688 (Process Creation) is key. If you see a PowerShell process creating a `rundll32.exe` or `reg.exe` process with unusual arguments, it’s worth investigating. To mitigate, ensure that Windows Defender Credential Guard is enabled to help block such attempts.
-
Data Exfiltration: Attackers can use PowerShell to connect to a remote server and upload data. Commands like `Invoke-WebRequest` or `[System.Net.WebClient]::UploadString` will be captured in Script Block Logging. A standard mitigation is to implement network segmentation and egress filtering to prevent unauthorized outbound connections from internal endpoints.
What Undercode Say:
- Key Takeaway 1: Visibility is the cornerstone of defense. Without comprehensive PowerShell logging, your SIEM is crippled. Attackers are using “living-off-the-land” techniques, meaning they don’t need to deploy malware; they just use what’s already there. Your primary defense is to log and monitor that usage.
- Key Takeaway 2: The future of detection lies in correlation and context. Individual events like 4104 or 4688 are just dots; the art of threat hunting is connecting them. A single Base64-encoded script block is suspicious, but when paired with a 7045 service creation event on a domain controller, it becomes a critical incident.
Prediction:
- +1: As AI-driven threat hunting tools become more sophisticated, the ability to parse and interpret Script Block Logging at machine speed will become the new standard, moving beyond signature-based detection to behavior-based profiling.
- -1: The advent of AI-generated, highly polymorphic and contextual PowerShell payloads will make it significantly harder for traditional and even some AI-based detection systems to distinguish between malicious and legitimate code, leading to a potential increase in false negatives.
- +1: The trend towards ‘Default Deny’ and application control policies will see a rise, forcing organizations to move from monitoring all PowerShell activity to explicitly allowing only a “known good” list of scripts, significantly reducing the attack surface.
- -1: The increasing use of encrypted or out-of-band C2 channels means that while you may log the execution of a script, the exfiltration of data may happen over a protocol like HTTPS, bypassing your logs unless you have robust network monitoring in place.
- +1: The democratization of threat intelligence, including community-driven Sigma rules for PowerShell event IDs, will empower smaller Blue Teams with enterprise-grade detection capabilities, leveling the playing field against well-resourced adversaries.
▶️ Related Video (76% Match):
https://www.youtube.com/watch?v=B6jQW6O02lk
🎯Let’s Practice For Free:
🎓 Live Courses & Certifications:
Join Undercode Academy for Verified Certifications
🚀 Request a Custom Project:
Secure, high-velocity infrastructure and disruptive technological engineering. Contact our engineering team for high-tier development and proprietary systems:
[email protected]
💎 Smart Architecture | 🛡️ Secure by Design | ⭐ Trusted by Thousands
IT/Security Reporter URL:
Reported By: Yildizokan Cybersecurity – Hackers Feeds
Extra Hub: Undercode MoN
Basic Verification: Pass ✅
