Scribd
Upload
24 views9 pages

PowerShell Logging Overview and Practices

This document discusses PowerShell logging, including the default engine and provider lifecycle event logging, suspicious script block logging, and optional script block, module, and transcription logging that can be enabled. It provides instructions for viewing logs, enabling additional logging, and interpreting log contents to understand PowerShell activity.

Uploaded by

Đình Hoàng
Copyright
© All Rights Reserved
We take content rights seriously. If you suspect this is your content, claim it here.
Available Formats
Download as DOCX, PDF, TXT or read online on Scribd
24 views9 pages

PowerShell Logging Overview and Practices

This document discusses PowerShell logging, including the default engine and provider lifecycle event logging, suspicious script block logging, and optional script block, module, and transcription logging that can be enabled. It provides instructions for viewing logs, enabling additional logging, and interpreting log contents to understand PowerShell activity.

Uploaded by

Đình Hoàng
Copyright
© All Rights Reserved
We take content rights seriously. If you suspect this is your content, claim it here.
Available Formats
Download as DOCX, PDF, TXT or read online on Scribd

PowerShell Logging

There are two types of logging enabled by default with PowerShell as


shown below.

1) Engine and Provider Lifecycle Events


2) Suspicious Script Block Logging

In addition to the very limited default logging, you can choose to enable 3
additional log types as follows.

1) Script Block Logging


2) Module Logging
3) Transcription Logging

Default Logging

First, we will look at the Engine and Provider Lifecycle events that are
written to the “Application and Services Logs  Windows PowerShell”
log. Open Event Viewer to this location to view these logs.

To open Event Viewer, do a search for “event viewer” in the search bar.

© 2022 DC8 LLC Page 1


© 2022 DC8 LLC Page 2
This log does not auto-update, so if you see the “New events available”
message you will need to click the refresh button to load them (or press
F5).

When you start PowerShell, an “Engine Lifecycle” event will be generated


(event ID 400). This event will show the PowerShell version being used and
can be used to identify a PowerShell downgrade attack. A PowerShell
downgrade attack is when an older version of PowerShell is used in order
to avoid the security mechanisms in place with later versions, like additional
logging options.

The second type of logging that is enabled by default is suspicious script


block logging. A script block is considered suspicious if it contains certain

© 2022 DC8 LLC Page 3


keywords like Add-Type, GetField, or NonPublic. Try running the
SuspiciousScript.ps1 file provided on your lab VM. You’ll see event ID 800
which logs the details of that script appear in the default PowerShell log.

The SuspiciousScript uses the Add-Type command, which is considered


suspicious. You can see the entire list of words considered suspicious by
executing the following PowerShell command.

[ScriptBlock].GetField('signatures','NonPublic,Static').GetValue($null) | sort

We haven’t enabled any of the optional logging yet, but if we look at the
Microsoft\Windows\PowerShell\Operational log we will see that these
suspicious scripts are being logged there as well. I’ve included a tool on the
desktop called TailPSopLog on the desktop of the lab VM that shows
these events without having to refresh the view. Double click the
TailPSopLog application and then run the Suspicious script again and
watch for the suspicious events to show in the log.

© 2022 DC8 LLC Page 4


Note: You will only see the Dark Yellow script block log the first time it is
run in each PowerShell session. You can start a new PowerShell window
and then execute the suspicious script again to ensure that you see that
log.

Try running one of the other sample scripts provided like,


AddNumbers.ps1. Do you see anything about its execution in any of the
logs?

Optional Logging

© 2022 DC8 LLC Page 5


Now let’s enable some of the optional logging and see what effect it has.
The logging options can be set by modifying specific registry keys or by
using Group Policy. I’ve included a tool for the class to be able to easily
turn logging on and off. To run the tool, double click on the LogMenu
shortcut from File Explorer and accept the UAC prompt by clicking Yes.

You now have an administrative PowerShell prompt where you can easily
set the logging options. If you want to see the details of what the script
does, review the Set-PSLogging.ps1 file in the Tools directory.

Choose option 1 to Enable-AllReasonableLogging.

© 2022 DC8 LLC Page 6


This will turn on script block, module, and transcription logging. It doesn’t
turn on Script Block Invocation Logging because it is very noisy and not
helpful. If you want to experiment with it to see, choose the Enable-
AllLogging option and watch for the red and green colored events.

Note: Logging options are set at the time the PowerShell window opens so
you must start a new PowerShell session to see the effects from the
logging changes you make.

Now start a new PowerShell session and execute some commands and
sample scripts. The color coding in the TailPSopLog tool will help clarify
which events are module logs (blue) or script block logs (yellow). If you see
a dark yellow log, that is a script block log with a level of warning that gets
generated from suspicious commands.

Note: If you ever see the word select in the title bar of the TailPSopLog or
the PowerShell window it means that output is paused. You won’t see any
additional output in a window with select in the title bar until you click in the
window and press the space bar. This will cause the output to continue to
flow to the screen.

© 2022 DC8 LLC Page 7


When you feel comfortable with what and how things are logged, use the
LogMenu to experiment with different settings. Remember, you need to
start a new PowerShell session for any logging settings to be reflected.

Note: Visual Studio code executes PowerShell commands in the


background even when you aren’t activity using it. It is best to have VS
Code closed when watching the logs to avoid unnecessary confusion.

Transcription logging is a different type of log than script block and module
logging. Transcription logging doesn’t show up in a Windows event log and
instead is written out to files. The directory for these files is configurable
and the LogMenu tool sets it to the C:\Users\IEUser\PSTranscripts
directory.

In the transcripts folder you will see a folder for each day and within each
folder you will find a text file for each PowerShell session that is created. A
transcript is an “over the shoulder” version of logging where you see

© 2022 DC8 LLC Page 8


everything that the user entering commands sees, including the output to
the screen.

In the example transcript above, you can see the effect of having double-
clicked the LogMenu shortcut (the Show-LoggingMenu.ps1 script was
executed). You can also see the menu that was output to the screen.

Look at the transcripts for your sessions to get familiar with the type of
information available to you from these logs.

This completes the introduction to PowerShell logging. In class we talked


about ways that attackers can bypass logging. You’ll get a chance to do
that in a later lab.

© 2022 DC8 LLC Page 9

Common questions

Powered by AI

Transcription logging is unique because it doesn't appear in Windows event logs but is instead written out to files in the C:\Users\IEUser\PSTranscripts directory. It provides a comprehensive view of commands entered and outputs seen during a session, akin to 'over the shoulder' logging .

Starting a new PowerShell session after changing logging settings ensures that the new configurations are applied and any newly executed commands are logged accurately. This practice maintains log integrity, ensuring that logs reflect the latest configuration settings and capture relevant data .

PowerShell logging can be modified by changing specific registry keys or using Group Policy to enable more detailed logging such as script block, module, and transcription logging. This is facilitated through tools like the LogMenu to easily turn logging on or off, requiring a new PowerShell session to apply these changes .

PowerShell logging helps identify downgrade attacks by logging engine lifecycle events, noting the version in use. If an older version is being used, it may indicate a downgrade attack, as older versions lack advanced logging and security features, thus making it easier to bypass security mechanisms .

Suspicious Script Block Logging identifies script blocks as suspicious if they contain certain keywords like Add-Type, GetField, or NonPublic. When such keywords are detected, the system logs these scripts as suspicious events, like event ID 800, helping to detect potentially harmful operations .

By default, PowerShell logging includes two primary types: Engine and Provider Lifecycle Events, and Suspicious Script Block Logging . Users can enable three additional log types: Script Block Logging, Module Logging, and Transcription Logging to enhance security monitoring .

Script Block Invocation Logging is often excluded because it is very noisy and not particularly helpful for most monitoring scenarios. This verbosity can overwhelm administrators with excessive log data, making it challenging to pinpoint actionable insights amid false positives .

To achieve more granular security insights, environments can enable optional logging types like Script Block, Module, and Transcription Logging. The LogMenu tool facilitates these settings by allowing easy toggling of logging options and requires a restart of the PowerShell session for changes to take effect .

Users should close Visual Studio Code when monitoring PowerShell logs to prevent interference since Visual Studio Code executes PowerShell commands in the background. This activity can cause confusion by cluttering logs with unnecessary events .

Real-time viewing of PowerShell logs is enhanced by using tools like TailPSopLog, which allows users to view events without the need for manual refreshing. It displays different types of logs with color coding to distinguish between log types, such as module logs in blue and warning-level script block logs in dark yellow .

You might also like