Thread by @SophosLabs

NEW: Reconstructing PowerShell scripts from multiple Windows event logs

On the trail of malicious #PowerShell artifacts too large to be contained in a single log? Help is on the way.

1/19

Adversaries continue to abuse PowerShell to execute malicious commands and scripts. It's easy to understand its popularity among attackers: Not only is it present on all versions of Windows by default (and crucial to so many Windows applications that few disable it)... 2/19

... this powerful interactive CLI and scripting environment can execute code in-memory without malware ever touching the disk. This poses a problem for defenders and researchers alike. 3/19

In a previous post, we explained various forensic artifacts left behind by PowerShell. With the release of PowerShell 5.0 back in 2015, Script Block Logging was enabled by default. 4/19

This feature records commands and entire scripts in event logs as they execute. If a script is very large, PowerShell breaks it into multiple parts before logging those under Event ID 4104, which will be the focus of this article. 5/19

The open-source community has a variety of effective tools to use when parsing or automatically hunting for suspicious events. In a recent post, we took a step-by-step look at decoding malicious PowerShell activity in a specific incident, using such tools. 6/19

However, the ability to extract or reconstruct (partially or in full) a very large PowerShell script from multiple event records is still lacking in most of the tools available. 7/19

When a large PowerShell script runs, it results in a number of fragmented artifacts deposited across multiple logs. Filtering for event ID 4104 returns a list of those artifacts. 8/19

The content of one of these artifacts, contained in the C:\Windows\System32\winevt\Logs\Microsoft-Windows-PowerShell%4Operational.evtx event log, is shown in the lower portion of the Event Viewer screen in Figure 1. 9/19

The ScriptBlock ID for this fragment, 51baf005-40a5-4878-ab90-5ecc51cab9af, appears on the right in Figure 2. 10/19

To create a single PowerShell object containing all the artifacts found with this process, open PowerShell ISE, replace the location of the offline EVTX (in our example, Operational.evtx) and ScriptBlock ID (in our example, 51baf005-40a5-4878-ab90-5ecc51cab9af)... 11/19

...and execute the following to create a single PowerShell object as shown in the example below. 12/19

In Figure 3, only a portion of the script is recorded in the event logs, specifically segments 97 to 121. Due to scheduled log rotation, dozens of segments are no longer available. 13/19

However, even partial data may be helpful during an incident-response investigation, making this extraction technique useful even when the condition of the log data cannot be ascertained prior to the operation. 14/19

To attempt the Listing and Extraction process via a simple script available on GitHub, use the PowerShell script ExtractAllScripts.ps1 by giving it the -List parameter, as shown in Figure 4. (As a convenience, we link to and show the full script at the end of this post.) 15/19

To extract selected scripts, give the ExtractAllScripts.ps1 script the -ScriptBlockID [ID] parameter. An excerpt from the script shows what happens behind the scenes: 16/19

PowerShell’s popularity among attackers stems in part from its ubiquity and its ability to run malicious code in memory.

Defenders must therefore examine whatever script traces may be found in logs, even if such traces may be scattered across multiple locations. 17/19

Since log-rotation intervals and script sizes both vary, the ultimate output of the process detailed in this post may retrieve some, most, or all of the script in question. The technique itself, however, enables defenders to make the most of what is available. 18/19

See more in the full article from @vikas891...

news.sophos.com/en-us/2022/03/…

19/19