The importance of PowerShell logs in digital forensics 

PowerShell is a powerful tool within Windows systems, widely used for administrative tasks, automation, and scripting. Unfortunately, due to its powerful scripting capabilities and default presence on Windows machines, it has also become a popular tool for malicious actors. PowerShell can be used in advanced attacks, including fileless malware, lateral movement within a network, and data exfiltration. This makes PowerShell logs an invaluable source of information for digital forensic investigations, particularly when dealing with network intrusions or insider threats.

This blog will explore the forensic importance of PowerShell logs and transcripts, their location, how they are populated, common challenges, and a use case involving a network intrusion scenario.

What are PowerShell logs?

PowerShell logs record various activities executed through PowerShell, including script execution, command history, and administrative tasks. Critical forensic artifacts allow investigators to track how PowerShell has been used (or misused) on a system. These logs can help identify both legitimate and malicious actions, especially in the context of a cyberattack.

PowerShell logs are divided into several key types:

1. Script block logging
2. Module logging
3. PowerShell operational logs
4. PowerShell transcripts
   
   

1. Script block logging

Script block logging captures all executed PowerShell code, including dynamically generated and potentially obfuscated scripts. Attackers often use script obfuscation to hide their activities, but with script block logging enabled, both the obfuscated and de-obfuscated versions of the scripts are logged. This can be critical for identifying malicious behavior that attempts to bypass security defenses.

2. Module logging

Module logging records the loading and execution of PowerShell modules. Modules are packages of cmdlets and functions that extend PowerShell’s capabilities, and attackers often use them as part of their attack workflows. By tracking which modules are loaded and executed, investigators can identify potentially suspicious activities, such as the use of the Invoke-WebRequest cmdlet for malicious purposes.

3. PowerShell operational logs

PowerShell’s operational logs contain metadata about scripts and commands, including information on when they were executed, which user executed them, and whether the execution was successful. These logs, stored under Event ID 4103 and 4104, can provide insights into the timeline of an attack and the specific commands used by the attacker.

For example, we can see from this Event 4104 log entry, we have some obfuscation:

If we examine the de-obfuscated text, we see additional obfuscation:

4. PowerShell transcripts

PowerShell transcription logging, when enabled, creates a detailed log of all commands and outputs within a PowerShell session. It captures the full context of PowerShell usage, including both the commands entered by a user or attacker and the output of those commands. Unlike the typical PowerShell event logs, which may only capture certain events or metadata, transcripts provide a much more comprehensive view of everything that happens in a PowerShell session.

Transcription logs can be created using the Start-Transcript cmdlet or through Group Policy settings. When enabled, these logs are often stored in a directory specified by the administrator, such as the user’s Documents folder or another designated logging directory.

This is an example of a PowerShell transcript from one of our test devices:

However, if the environment does not have transcription logging enabled, you can also locate a console host command history, which is placed into the user directory at:

C:\Users\<Username>\AppData\Roaming\Microsoft\Windows\PowerShell\PSReadLine\ConsoleHost_History.txt.  It will contain inputted commands, but not replies.  Here we see an example of this:

Transcripts are highly valuable in forensic investigations as they contain detailed information about what was executed and the result, providing deeper insights into an attacker’s intent and behavior.

Where PowerShell logs are located

PowerShell logs, including script block logging, module logging, and operational logs, are stored within the Windows Event Viewer, specifically under:

1. Windows PowerShell log:
   • Path: Applications and Services Logs > Windows PowerShell
   • Description: Captures session start and stop events, along with some basic execution details.
2. Microsoft-Windows-PowerShell/Operational log:
   • Path: Applications and Services logs > Microsoft > Windows > PowerShell > Operational
   • Description: Contains detailed execution logs of scripts, including metadata about commands and events such as script block logging (Event ID 4104)
3. PowerShell Transcripts:
   • Path: Typically stored in a user-defined or administrator-configured directory such as C:\Users\<UserName>\Documents\PowerShell_Transcripts.
   • While PowerShell logs are centrally stored within the event logs, transcription logs are stored in a designated location, making them separate but equally valuable for investigation.

How are PowerShell logs populated?

By default, PowerShell logging features are often minimal, and some critical logging features must be specifically enabled to capture the full range of activities. Here’s how these logs are populated:

1. Script block logging: This is not enabled by default. Administrators need to enable it via Group Policy or through PowerShell itself. Path: Computer Configuration -> Administrative Templates -> Windows Components -> Windows PowerShell -> Turn on PowerShell Script Block Logging
2. Module logging: This must also be enabled via Group Policy. Path: Computer Configuration -> Administrative Templates -> Windows Components -> Windows PowerShell -> Turn on Module Logging
3. Operational logs: These logs are usually enabled by default but may need retention settings adjusted to prevent log overwriting.
4. Transcription logging: This can be enabled through Group Policy or by running the Start-Transcript cmdlet within PowerShell. Once enabled, it captures full session data and stores it in a specified directory. To enable it via Group Policy: Path: Computer Configuration -> Administrative Templates -> Windows Components -> Windows PowerShell -> Turn on PowerShell Transcription

These logging features capture activity in real time, providing investigators with vital evidence of system activities, script execution, and potential compromises.

Pitfalls and challenges with PowerShell logs

Despite their utility, there are several challenges associated with using PowerShell logs in forensic investigations:

1. Not enabled by default: Many key logging features, such as Script Block Logging and Transcription Logging, are not enabled by default. This can result in critical gaps in the timeline if an organization has not proactively configured logging.
2. Log overwriting and retention: PowerShell logs, especially operational logs, can be overwritten if log retention settings are not properly configured. In high-traffic environments, logs may be overwritten before they can be analyzed, causing a loss of forensic evidence.
3. Log manipulation: Attackers may attempt to clear or disable logs to cover their tracks. While log clearing itself generates an event, the loss of detailed logs could hinder an investigation.
4. Obfuscation: Malicious PowerShell scripts are often obfuscated to hide their true intent. While Script Block Logging captures both obfuscated and de-obfuscated code, the analysis may still require additional tools to fully understand the attack .
5. Sheer volume: In environments with heavy PowerShell use, the sheer volume of logs can become overwhelming. Automated tools or scripts may be necessary to parse and filter the logs for suspicious activity.

Use Case: network intrusion involving PowerShell

Consider a scenario in which an organization detects unusual outbound network traffic from one of its internal servers. Upon further analysis, it’s determined that PowerShell commands are involved, and a forensic investigation is initiated.

1. Initial discovery: The forensic team dumps the PowerShell operational logs and transcription logs from the affected server. They find a series of suspicious Event ID 4104 entries (Script Block Logging) in the operational logs, showing that obfuscated PowerShell commands have been executed.
2. De-obfuscation: The investigators use tools like CyberChef to de-obfuscate the scripts, which reveal attempts to establish a reverse shell connection with an external command-and-control (C2) server.
3. Transcription logs review: The transcription logs provide a full record of the PowerShell session, including commands that listed network shares, copied sensitive files, and sent them to an external IP address. These logs show exactly what data was exfiltrated.
4. Attack timeline: Using both the Script Block logs and the transcription data, the investigators piece together the timeline of the attack. They identify the initial phishing email that led to the attacker gaining access and executing the PowerShell commands remotely.
5. Remediation: With the attack fully documented, the organization can block the C2 server, close the vulnerability, and take steps to prevent similar attacks in the future.

Conclusion

PowerShell logs, especially when combined with transcription data, are critical in understanding how PowerShell is used in both legitimate and malicious contexts. While there are challenges, such as the need for proactive configuration and the potential for log manipulation, these logs are indispensable in digital forensic investigations. By leveraging PowerShell logs and transcripts, investigators can trace attackers’ actions, identify the tools they used, and gain valuable insights into the nature of a compromise.