PowerShell Logging
PowerShell logging is a critical element of security monitoring in modern environments, as PowerShell is often used by attackers to execute malicious scripts, bypass defenses, and perform attacks. Enabling PowerShell logging allows you to monitor the commands and scripts that are executed, which helps detect suspicious activity.
Setting up Powershell logging
To configure PowerShell event auditing using Group Policies and enable the Script Block Logging module, run
Open Group Policy Editor
Go to the section: Computer Configuration β Policies β Administrative Templates β Windows Components β Windows PowerShell.
Select "Enable module logging", "Enable script block logging" and "Enable transcription logging" For the latter, specify the path to save the transcripts (e.g.
C:\PSLogs).
Event Types
Main types of logging:
PowerShell Audit Module (Module Logging) - The audit module logs all commands executed in PowerShell. Logs are saved in Windows Event Log under Microsoft-Windows-PowerShell/Operational with Event ID 4103 Register: - Individual commands executed in PowerShell. - If the script is running, then a separate event will be registered for each Powershell Cmdlet call - If an alias is used (e.g.
gciinstead ofGet-ChildItem), theGet-ChildItemcmdlet will be written to the logs.\Script Block Logging - Script Block Logging records the contents of scripts executed in PowerShell. Logs are saved in Windows Event Log under Microsoft-Windows-PowerShell/Operational with Event ID 4104 Registered**:** - Full contents of scripts executed in PowerShell. - The entire block of code is logged, including commands, loops, conditions and functions.
If the PowerShell script is very long, event ID 4104 is logged as multiple events. In each event you will find a Script Block field, which contains the body part of the script. Also, each event contains an indication of how many blocks the script was split into (MessageTotal) and the current sequence number (MessageNumber).
Transcript Logging. Transcription logging saves all actions performed in a PowerShell session to a text file.
We usually only use 4103 and 4104
Comparison of PowerShell events Event ID 4103 and Event ID 4104
Both events are related to logging PowerShell activity, but they record different aspects of command and script execution.
Executing a script from a file
Let's assume that the attacker launches Powershell and executes the script add_admin.ps1. This will register Event ID 4104, where the ScriptBlockText field will contain the full body of the script:
In this case, 4 separate Event ID 4103 events will be registered, in the Payload field there will be corresponding entries for each invoked cmdlet:
In this case, Script Name in ContextInfo of each Event ID 4103 will contain the full path to the add_admin.ps1 script.
It is worth noting that Event Id 4103 shows the specific values ββof what is passed as parameters in the script body.
Cmdlet aliases in Event ID 4103
Powershell cmdlets have aliases β a short or alternative name for a cmdlet, function, or script. Aliases allow you to enter commands faster, saving time. Some are already defined in the system, but you can also specify custom ones.
If you enter an alias in the powershell console, then in Event ID 4104 it will be logged as entered by the user, but in 4103 the original full cmdlet will be visible
That is, obfuscation with properly configured powershell logging practically loses its usefulness. Although it is sometimes useful to simply look for its traces.
Examples of obfuscations
Starting a process from Powershell
If the attacker simply launches a process from powershell, then under the hood a call to the Invoke-Expression cmdlet is generated.
If an attacker starts a Powershell process like this:
Then in the process start event (Event ID 4688, Sysmon 1) we will see an encrypted base64 string (You can decrypt it in CyberChef). However, in EventID 4103 and 4104 you will see what was actually executed:
Well-known Powershell tools
All of them include fairly specific cmdlets, the detections for which will not be sophisticated, but will definitely be useful.
Examples of suspicious commands and scripts
Downloading and executing scripts from the Internet: Look for commands related to bypassing protection, running scripts, or interacting with external resources (e.g.
FromBase64StringDownloadString,Net.WebClient)Bypass protection:
Creating hidden processes:
Using hacking utilities:
Last updated
Was this helpful?