PCAParse

I was doing some research recently regarding what's new to Windows 11, and ran across an interesting artifact, which seems to be referred to as "PCA". I found a couple of interesting references regarding this artifact, such as this one from Sygnia, and this one from AboutDFIR. Taking a look at the samples of files available from the DFIRArtifactMuseum, I wrote a parser for two of the files from the C:\Windows\appcompat\pca folder, converting the time stamps to Unix epoch format and sending the output to STDOUT, in TLN format so that it can be redirected to an events file.

An excerpt from the output from the PcaAppLaunchDic.txt file:

1654524437|PCA|||C:\ProgramData\ProtonVPN\Updates\ProtonVPN_win_v2.0.0.exe
1661428304|PCA|||C:\Windows\SysWOW64\msiexec.exe
1671064714|PCA|||C:\Program Files (x86)\Proton Technologies\ProtonVPN\ProtonVPN.exe
1654780550|PCA|||C:\Program Files\Microsoft OneDrive\22.116.0529.0002\Microsoft.SharePoint.exe

An excerpt from the output from the PcaGeneralDb0.txt file:

1652387261|PCA|||%programfiles%\freefilesync\bin\freefilesync_x64.exe - Abnormal process exit with code 0x2
1652387261|PCA|||%programfiles%\freefilesync\freefilesync.exe - Abnormal process exit with code 0x2
1652391162|PCA|||%USERPROFILE%\appdata\local\githubdesktop\app-2.9.9\resources\app\git\cmd\git.exe - Abnormal process exit with code 0x80
1652391162|PCA|||%USERPROFILE%\appdata\local\githubdesktop\app-2.9.9\resources\app\git\mingw64\bin\git.exe - Abnormal process exit with code 0x80

This output can be redirected to an events file, and included in a timeline, so that we can validate that the artifact does, in fact, illustrate evidence of execution. Incorporating file system information, Prefect and Windows Event Log data (and any other on-disk resources), as well as EDR telemetry (if available) will provide the necessary data to validate program execution.

Addendum, 2024-02-27: Okay, so I've been actively seeking out opportunities to use this parser in my role at my day job, and while I've been doing so, some things have occurred to me. First, there's nothing in either file that points to a specific user, so incorporating this data into an overall timeline that includes WEVTX data and EDR telemetry is going to help not only validate the information from the file themselves, but provide the necessary insight around process execution, depending of course on the availability of information. Fossilization on Windows systems is a wonderful thing, but not everyone takes advantage of it, nor really understands where it's simply not going to be available.

Not only is there no user information, there's also no information regarding process lineage. Still, I firmly believe that once we begin using this information in a consolidated timeline, and begin validating the information, we'll see that it adds yet another clarifying overlay to our timeline, as well as possible pivot points.

A Look At Threat Intel, Through The Lens Of The r77 Rootkit

It's been almost a year, but this Elastic Security write-up on the r77 rootkit popped up on my radar recently, so I thought it would be useful to do a walk-through of how someone with my background would mine open reporting such as this for actionable intel. 

In this case, the r77 rootkit is described as an "open source userland rootkit used to deploy the XMRig crypto miner". I've seen XMRig before (several times), but not deployed alongside a rootkit.

The purpose of a rootkit is to hide stuff. Anyone who was around in the late '90s and early 2000s is familiar with the term "rootkit" and what it means. From the article, "r77’s primary purpose is to hide the presence of other software on a system by hooking important Windows APIs, making it an ideal tool for cybercriminals looking to carry out stealthy attacks. By leveraging the r77 rootkit, the authors of the malicious crypto miner were able to evade detection and continue their campaign undetected."

My point in sharing this definition/explanation is because many of us will see this, or generally accept that a rootkit is involved, and then not think critically about what we're seeing, but more importantly, what we're not seeing. For example, in this case, the Elastic Security write-up

The installer module is described as being written to the Registry, which is a commonly observed technique, especially when it comes to "fileless malware". The article states that the installer "creates a new registry key called $77stager in the HKEY_LOCAL_MACHINE\SOFTWARE hive and writes the stager module to the key." However, the code in the image immediately following that statement (images are not numbered in the article) shows the RegSetValueExW function being called. As such, it's not a Registry key that's created, but a value. 

This may seem pedantic to many, but the distinction is important. Clearly, a different API function is used to create a value than a key; this is because keys and values are completely different structures all together. You cannot write data to a key (i.e., "writes the stager module to the key"), that data has to be associated with a value. Many EDR frameworks, when monitoring or querying Registry keys vs values, use different API or function calls themselves. As such, monitoring for the creation of or simply searching for the $77stager key will miss this rootkit. 

Every. 

Single. 

Time. 

What's interesting is that the article later states:
It then stores the current process ID running the service module as a value in a registry key named either “svc32” or “svc64” under the key HKEY_LOCAL_MACHINE** SOFTWARE$77config\pid**. The svc32/64 key name is based on the system architecture.

Here, it looks as if the correct nomenclature is used.

And then there's threat hunting; that is, if you're going to write PowerShell code to sweep across your infrastructure and look for malware similar to this, the code to look for a key is different than that to look for a value. The same is true for triage or 'dead box' analysis via tools such as RegRipper. Threat hunting with PowerShell across live systems for direct artifacts of this rootkit likely won't get you very far, because...well...it's a rootkit, and the key is hidden through the use of userland API hooking. Elastic's article even points out that data is filtered when using tools such as RegEdit that rely on the hooked API functions. As such, verifying that the rootkit is actually there may require the use of reg.exe of something like FTK Imager to copy the Software hive off of the endpoint, and then parsing that hive file.

Searching for indirect artifacts related to this rootkit, however, is an entirely different matter, and is the reason why indirect artifacts are so valuable. The PowerShell code that is launched is captured in the Windows PowerShell Event Log, in PowerShell/600 event records, as well as in the Microsoft-Windows-PowerShell/Operational Event Log, in Microsoft-Windows-PowerShell/4104 records. This activity/these artifacts allow us to validate that the activity actually occurred, while providing for additional detection opportunities.

Some aspects of the malware not covered in the article include initial access, or how the whole kit is deployed. The technical depth of the article is impressive but not entirely actionable. For example, what aspects (direct artifacts) of the infection are hidden by the rootkit, and what indirect artifacts are 'visible'?