PowerShell remoting artifacts: An introduction
Since PowerShell usage by malware is on the rise, in this article series, we will learn about the various artifacts related to PowerShell remoting that can be very beneficial during the investigation and during building stories around Attack Chain. This article series will focus on different types of artifacts like network traffic, memory artifacts, registry artifacts, Event logs, etc. In this article, we will focus on EventIDs related to PowerShell Remoting.
Before we start looking at different eventIDs, first note that below are the common locations of event logs written during local or remote PowerShell session
- Windows Powershell.evtx
- Microsoft-Windows-Powershell/Analytic.etl (If enabled)
EventIDs of interest
- EventID: 400 &403
These EventIDs are used to mark the beginning and end of the session. Below is a screenshot for 400
The event is marked with “Engine state is changed from None to Available.”
From Details tab we can find additional information:
HostName=ServerRemoteHost indicates that the session is remote. If the session would have been local, then the Hostname will be ConsoleHost
Similarly, EventID 43 marks the end of the session. The event is marked by “Engine state is changed from Available to stopped.”
Below is the snapshot from Detail view:
- EventID: 169: This event marks the beginning of remoting activity on the target system. We can also see the type of auth mechanism and user name used to access WinRM.
Here we can see that user has authenticated with NTLM authentication. This will be useful to know the compromised account which is used by malware to pivot between systems.
- EventId: 81, 82,134: These EventIDs record the background actions during a PowerShell session which mean that these EventIDs collect low-level messages. These EventIDs are useful for defining the timeframe for a remote session. Below is a sequence of screenshots for these EventIDs.
- Creation of a session
- EventID: 81: marked by String: “Processing Client request for operation CreateShell.” This is when the client has started processing request from remote for creating the Shell. For remote shell to b spawned, it should be enabled. If it is disabled, then the respective log is 142.
- Creation of a session
EventID: 82: This is marked by “Entering the plugin for opening shell.”
- EventId:134: Marked by “Sending response for operation CreateShell.” This is depositing the response for EventID 81.
Below are some other sequence of events for these 3 EventIds
- EventID: 81: Marked for Processing Client Command
- EventID: 82: Invoke the plugin for command
- EventID: 134: Output of command execution
- The sequence of EventDs for Shell Deletion:
- EventID: 81: Marked for processing client request for operation Delete Shell.
- EventID:82: Invoking the plugin for operation DeleteShell
- EventID:134: Sending the response back of the DeleteShell.
- EventId: 32850: This is logged under Microsoft-Windows-PowerShell analytics logs. This category has to be specifically enabled. This will tell us that which user has created a remote session. Must be combined with other EventIds to verify the username as well as to build the remoting activity.
- EventID: 32867: This EventID is used to log input messages during remoting session. Complete messages are often split into fragments which mean to get the context we should check all fragments within a timeframe which we can build from earlier discussed EVENTIDs.
- The objects are hexadecimal encoded and are stored in Payload data.
- EventID: 32868: This EventID is used to log output/response messages during remoting session. Complete messages are often split into fragments which mean to get the context we should check all fragments within a timeframe which we can build from earlier discussed EVENTIDs.
The objects are hexadecimal encoded and are stored in Payload data. Following are decoded snippets from various fragments:
Looking at the output from various fragments, it looks like C: drive is being enumerated which means that Get-ChildItem is probably executed.
There are some advanced logging features as well for PowerShell now which can increase the forensic artifacts volume. For example, enabling Module Logging can help you to determine the module invoked during remoting directly.
EventID for module logging is 4103 and is stored under Microsoft Windows Powershell Operational logs.
So these are about EventIDs related to PowerShell remoting. In the next article in this series, we will take a look at the registry settings, network and memory artifacts.