Unmasking the Adversary: How PowerShell Logging Exposes the Attacks Your SIEM is Missing + Video

By /

Listen to this Post

Featured Image

Introduction:

In modern Windows environments, PowerShell is a double-edged sword, offering unparalleled administrative power to both IT professionals and cyber adversaries. For Security Operations Center (SOC) analysts, the lack of comprehensive PowerShell telemetry represents a critical visibility gap, allowing attackers to execute fileless attacks, lateral movement, and data exfiltration under the radar. This article details the essential logging mechanisms required to transform this blind spot into a rich source of actionable threat intelligence and forensic evidence.

Learning Objectives:

  • Understand the four critical PowerShell logging mechanisms and their specific Event IDs.
  • Learn how to implement and configure these logs via Group Policy and local settings.
  • Develop the skills to centralize these logs and create proactive detection rules for common attacker TTPs.

You Should Know:

  1. Enabling the Foundational Logs: A Group Policy Odyssey
    PowerShell logging is not fully enabled by default. The most robust method for enterprise deployment is via Group Policy, which ensures consistent configuration across all Windows endpoints.

Step-by-step guide:

  1. Open the Group Policy Management Console (GPMC.msc) and edit the policy targeting your workstations/servers.
  2. Navigate to: `Computer Configuration` > `Administrative Templates` > `Windows Components` > Windows PowerShell.

3. Enable the following policies:

Turn on PowerShell Script Block Logging: Set to Enabled. Consider enabling the “Log script block invocation start / stop events” option for deeper sequencing.
Turn on PowerShell Transcription: Set to Enabled. Configure a central output directory (e.g., \\SIEM\PowerShellTranscripts\<Date>). Warning: Ensure secure permissions on this share to prevent attackers from reading their own transcripts.
4. For Module Logging, you must use a PowerShell command to configure it via GPP or deploy via script, as it lacks a direct GPO. The cmdlet is:

 This sets Module Logging for all modules (). Run this on a reference machine and export via <code>Export-CliXml</code>.
$moduleLogging = @{
Name = 'PowerShellCore'
ModuleNames = @('')
Enabled = $true
}
New-WinEvent -SourceIdentifier 'PowerShell' -LogName 'Windows PowerShell' -Settings $moduleLogging

5. Link the GPO and force a refresh on a test machine with gpupdate /force.

  1. Script Block Logging (Event ID 4104): Your Weapon Against Obfuscation
    This is the most critical log. It records the content of every PowerShell script block that is executed, including heavily obfuscated and encoded commands that attackers use to evade signature-based tools.

Step-by-step guide:

  1. After enabling via GPO, logs are written to the `Microsoft-Windows-PowerShell/Operational` event channel.

2. To query these events locally for investigation:

Get-WinEvent -LogName "Microsoft-Windows-PowerShell/Operational" | Where-Object {$_.Id -eq 4104} | Select-Object -First 5 -Property TimeCreated, Message

3. In your SIEM, craft detections for indicators of obfuscation:
Excessive use of tick marks, backslashes, or concatenation.

High entropy strings (long, random-looking character sequences).

Keywords like `-EncodedCommand`, `-e`, `-enc`, `IEX`, `Invoke-Expression`.

  1. A sample Sigma detection rule (YAML) for encoded commands: 
    title: PowerShell Base64 Encoded Command
status: experimental
logsource:
product: windows
service: powershell
detection:
selection:
EventID: 4104
CommandLine|contains: </li>
</ol>

- '-EncodedCommand'
- '-e '
- '-enc '
condition: selection
level: high
    1. Module Logging (Event ID 4103) & Transcription: Capturing the Execution Pipeline
      While Script Block Logging shows what was run, Module Logging reveals how it was executed through the pipeline. Transcription creates a text-based transcript of the entire PowerShell session, including command output.

    Step-by-step guide for Module Logging:

    1. Configure Module Logging to capture deep execution details. This can be done via the `PowerShell` console with administrative rights: 
      Enable for all modules (can be resource-intensive)
Set-PSReadlineOption -HistorySaveStyle SaveIncrementally
More targeted: Enable for specific high-risk modules like -WebRequest, -Item, etc.
    2. Events are stored in the `Windows PowerShell` log. Key fields include RunspaceId, PipelineId, and the detailed `Message` of each pipeline step.
    3. Use this to trace the step-by-step execution of a malicious script, understanding each transformation of data.

    4. Process Creation Auditing (Event ID 4688) & Sysmon (Event ID 1): The Parent-Child Story
      Understanding how PowerShell was spawned is crucial. Was it launched by an Office macro, a malicious PDF, or a exploited web service? Native Windows auditing and Sysmon provide this context.

    Step-by-step guide:

    1. Enable Process Creation Auditing via GPO: `Computer Configuration` > `Policies` > `Windows Settings` > `Security Settings` > `Advanced Audit Policy Configuration` > `Audit Policies` > `Detailed Tracking` > `Audit Process Creation` (set to `Success` and Failure).
    2. For superior detail, deploy Sysmon with a configuration that emphasizes parent-child relationships. 
      <!-- Sysmon Config Snippet (SysmonConfig.xml) -->
<ProcessCreate onmatch="include">
<Rule groupRelation="or">
<Image condition="end with">powershell.exe</Image>
<ParentImage condition="end with">winword.exe</ParentImage>
<ParentImage condition="end with">excel.exe</ParentImage>
<ParentImage condition="end with">outlook.exe</ParentImage>
<ParentImage condition="end with">mshta.exe</ParentImage>
</Rule>
</ProcessCreate>

    3. Install Sysmon: `Sysmon64.exe -i SysmonConfig.xml -accepteula`.

    1. Correlate Sysmon Event ID 1 (Process creation) with PowerShell 4104/4103 events using the `ProcessId` and `ParentProcessId` fields.

    2. Centralizing Logs and Building Detections in Your SIEM
      Raw logs are useless if not collected and analyzed. Centralization enables correlation and automated alerting.

    Step-by-step guide:

    1. Configure a Windows Event Collector or use your SIEM agent to forward critical logs:

    `Microsoft-Windows-PowerShell/Operational`

    `Windows PowerShell`

    `Security` (for 4688)

    `Microsoft-Windows-Sysmon/Operational`

    1. In your SIEM (e.g., Splunk, Elasticsearch), create correlation searches. Example: “PowerShell spawned by an unexpected parent (e.g., outlook.exe) AND contains a base64 encoded command.”

    3. Build a dashboard tracking:

    Unique hosts generating 4104 events.

    Top scripts being executed.

    Parent processes of `powershell.exe`.

    What Undercode Say:

    • Visibility is Non-Negotiable: PowerShell logging is a foundational security control, not an optional extra. An environment without it is operating with a deliberate and significant deficit in defensive capability.
    • Correlation is King: The true power of these logs is unlocked by correlating Script Block details (the what) with Process Creation data (the how and why). This context is what allows analysts to pivot from detection to understanding the full attack chain.

    Prediction:

    As Endpoint Detection and Response (EDR) solutions become more adept at catching classic PowerShell abuse, adversaries will continue to evolve. We will see a rise in “living-off-the-land” (LOL) techniques using other, less-monitored Windows components like CSCRIPT, WMI, or the .NET runtime directly. Furthermore, attackers will increasingly leverage AI-generated code to create polymorphic, context-aware scripts designed to mimic legitimate administrative activity, making pattern-based detection harder. The future of defensive PowerShell telemetry will hinge on behavioral analytics and machine learning models that baseline normal administrative use and flag anomalous sequences of actions, regardless of the specific commands or obfuscation used. The arms race moves from the command line to the behavioral layer.

    ▶️ Related Video (82% Match):

    🎯Let’s Practice For Free:

    IT/Security Reporter URL:

    Reported By: Paschal Emechebe – Hackers Feeds
    Extra Hub: Undercode MoN
    Basic Verification: Pass ✅

    🔐JOIN OUR CYBER WORLD [ CVE News • HackMonitor • UndercodeNews ]

    💬 Whatsapp | 💬 Telegram

    📢 Follow UndercodeTesting & Stay Tuned:

    𝕏 formerly Twitter 🐦 | @ Threads | 🔗 Linkedin | 🦋BlueSky

Related Posts: