Windows DFIR notes are no longer maintained on InfoSec-Notes. Updated versions can be found on: artefacts.help.
Overview
Windows PowerShell version 2.0, and prior versions, provide few useful audit settings, thereby limiting the availability of evidence (such as a command history).
Upon executing any PowerShell command or script, either locally or using PS remoting, Windows may write events to the following hives:
Starting with PowerShell v5 on Windows 10, the commands entered in a PowerShell console will be logged by the PSReadline module to an user-scoped ConsoleHost_history.txt file. Console-less PowerShell sessions, such as the content of PowerShell script or commands execution through the PowerShell ISE, will not be logged in this file. By default, the ConsoleHost_history.txt file will be located under: $env:APPDATA\Microsoft\Windows\PowerShell\PSReadLine\ConsoleHost_history.txt. Bypassing PSReadline logging is however easy, as it simply requires to unload the PSReadline module (for instance with the Remove-Module PSReadline in an existing PowerShell session).
As PowerShell implements its remoting functionality through the Windows Remote Management (WinRM) service, remote PowerShell activity may induce events in the following hives:
The events linked to remote PowerShell activity, conducted through the WinRM service, are detailed in the Lateral movements section.
Additionally, if enabled, AppLocker will record PowerShell activity in the Microsoft-Windows-AppLocker\MSI and Script hive.
Note that PowerShell 2.0, and prior versions, provide limited logging capacities and thereby limit the availability of evidence, such as the interactive command history executed through PowerShell console.
The events providing command line / command history information should be searched for the following keywords (case insensitive search):
While the occurrence of these keywords may entail malicious activities, their absence is not a formal proof of lack of malicious PowerShell activity as PowerShell code can be deeply obfuscated.
PowerShell deobfuscation
The PSDecode PowerShell script can be used to deobfuscate malicious PowerShell scripts that have several layers of encodings.
Engine state is changed from None to Available.
Logged on the start of any local or remote PowerShell activity (execution of powershell.exe).
The HostApplication field record the binary path at the origin of the powershell activity and contain the commandline arguments provided to powershell.exe.
If the Hostname field is equal to :
- ConsoleHost, the event concern a local activity
- ServerRemoteHost, the event occured du to PowerShell remoting activity.
The RunaspaceId identify the PowerShell activity and can be linked to the session termination (EID 403). Note that however this event cannot be strictly correlated to a logon session.
Windows PowerShell
403
PowerShell 2.0
Engine state is changed from Available to Stopped.
Logged at the end of any local or remote PowerShell activity (execution of powershell.exe) and contains the same level of information as the EID 400 events.
The RunaspaceId identify the PowerShell activity and can be linked to the session start (EID 400). Note that however this event cannot be strictly correlated to a logon session.
Windows PowerShell
500
PowerShell 2.0
Requires $LogCommandLifeCycleEvent to be set to true (non default)
Command "<COMMAND>" is Started.
Logged whenever a PowerShell command is executed, but can be bypassed by starting PowerShell using the -NoProfile / -nop flag.
Windows PowerShell
501
PowerShell 2.0
Requires $LogCommandLifeCycleEvent to be set to true (non default)
Command "<COMMAND>" is Stopped.
Logged whenever a PowerShell command finish its execution, but can be bypassed by starting PowerShell using the -NoProfile / -nop flag.
Windows PowerShell
600
PowerShell 2.0
Provider "<PROVIDER_NAME>" is Started.
Logs the start and stop of PowerShell providers.
Similarly to the events EID 400 and EID 403, this event include the HostApplication field.
If the provider is WSMan ("Provider WSMan Is Started"), the event, logged on both the client and remote systems, indicate the use of PS remoting.
If the PowerShell activity relies on built-in alias, such as IEX, an event will be generated for the Alias provider.
Windows PowerShell
800
PowerShell 3.0
Pipeline execution details for command line.
Inconsistently logged.
Similarly to the events EID 400 and EID 403, this event include the HostApplication field and present the advantage of logging, in the UserId field, the user account executing PowerShell.
Microsoft-Windows-PowerShell\Operational
4100
PowerShell 5.0
Error message [...].
Logged whenever an error occurs in a PowerShell activity.
Includes an HostApplication field, the <DOMAIN>\<USER> executing PowerShell in the User field, and may include the script path of the executed script in the ScriptName field.
Microsoft-Windows-PowerShell\Operational
4103
PowerShell 3.0
Requires PowerShell Module Logging to be enabled (EnableModuleLogging registry key set to 1)
Module Logging.
Logged upon the execution of functions in the module(s) set to be logged.
If the module names, configured in the Software\Policies\Microsoft\Windows\PowerShell\ModuleLogging\ModuleNames registry key, is set to *, the activity of the members of all modules are logged.
Provides verbose information on the PowerShell activity and, in addition to user information, events may yields the parameters and output of the executed PowerShell cmdlets.
Microsoft-Windows-PowerShell\Operational
4104
PowerShell 5.0
Requires PowerShell Script Block Logging to be enabled to generate all events.
By default (without a specific policy), events will however be logged for potentially-malicious commands execution. The following ressource lists the suspicious strings used by PowerShell SuspiciousContentChecker function to trigger an event creation.
Script block logging: Creating Scriptblock text [...].
Logged upon the execution of PowerShell scripts and cmdlets.
If the Path field is empty, the command was executed interactively through the PowerShell console.
Includes, in the ScriptBlockText field, the script block (content of the PowerShell script or cmdlet and the commandline) being executed.
This event provides valuable information but may be bypassed by malicious actors by starting PowerShell 2.0 (powershell.exe -version 2.0).
Microsoft-Windows-PowerShell\Operational
40961
40962
PowerShell 3.0
PowerShell console is starting up (EID 40961) followed by PowerShell console is ready for user input (EID 40962).
Logged upon the start of a PowerShell activity (execution of powershell.exe).
Includes the <DOMAIN>\<USER> executing PowerShell in the User field.
Microsoft-Windows-PowerShell\Operational
53504
PowerShell 3.0
Windows PowerShell has started an IPC listening thread on process: <PID> in AppDomain: <DOMAIN>.
Indicates that a PowerShell AppDomain was started.
Usually logged upon the start of the PowerShell console, in between events EID: 40961 and EID: 40962.
Microsoft-Windows-WinRM\Operational
WinRM events on destination host.
91
-
Creating WSMan shell on server with ResourceUri: <X>.
Indicates that a remote WinRM session was opened.
Includes the domain and username of the user that opened the session but not the source host.
Microsoft-Windows-WinRM\Operational
WinRM events on source host.
6
8
15
16
31
33
-
Event 6: Creating WSMan Session. The connection string is: <REMOTE_HOST>/wsman?PSVersion=XXX.
Indicates that a WinRM session was opened on a remote host.
Includes the domain and username of the currently logged-on user (not necessarily the user that was used to open the session) and the remote host information.
Event 33: Closing WSMan Session completed successfuly
Indicates that a WinRM session was closed, with no information on the session or the remote host, only the currently logged-on user.
Events 8, 15, 16, and 31: other events that occur during the life-cycle of the WinRM session.
Microsoft-Windows-AppLocker\MSI and Script
8005
Require AppLocker to be enabled and running in Audit only mode
<SCRIPT_PATH> was allowed to run.
Logged upon the execution of a local PowerShell script.
Microsoft-Windows-AppLocker\MSI and Script
8006
Require AppLocker to be enabled and running in Audit only mode
<SCRIPT_PATH> was allowed to run but would have been prevented from running if the AppLocker policy were enforced.
Logged upon the execution of a local PowerShell script.
Security
4688
Requires Audit Process Creation to be enabled
A new process has been created.
Logged upon the creation of every process. The NewProcessName field stores the full path of the process's executable and will contain powershell.exe for PowerShell activity.
Refer to the Processes section for more information on this event.
