Updates and Stuff

Registry Analysis
I received a question recently, asking if it were possible to manipulate Registry key LastWrite time stamps in a manner similar to file system time stomping.  Page 30 of Windows Registry Forensics addresses this; there's a Warning sidebar on that page that refers to SetRegTime, which directly answers this question.

The second part of the question was asking if I'd ever seen this in the wild, and to this point, I haven't.  Then I thought to myself, how would I identify or confirm this?   I think one way would be to make use of historical data within the acquired image; let's say that the key in question is available within Software hive, with a LastWrite time of 6 months prior to the image being acquired.  I'd start by examining the Software hive within the RegBack folder, as well as the Software hives within any available VSCs.  So, if the key has a LastWrite time of 6 months ago, and the Software hive from the RegBack folder was created 4 days ago and does NOT include any indication of the key existing, then you might have an issue where the key was created and time stomped.

Powershell Logging
I personally don't use Powershell (much, yet), but there have been times when I've been investigating a Windows system and found some entries in the Powershell Event Log that do little more than tell me that something happened.  While conducting analysis, I have no idea if the use of Powershell is pervasive throughout the infrastructure, if it's something one or two admins prefer to use, or if it was used by an attacker...the limited information available by default doesn't give me much of a view into what happened on the system.

The good news is that we can fix this; FireEye provides some valuable instructions for enabling a much greater level of visibility within the Windows Event Log regarding activity that may have occurred via Powershell.  This Powershell Logging Cheat Sheet provides an easy reference for enabling a lot of FireEye's recommendations.

So, what does this mean to an incident responder?

Well, if you're investigating Powershell-based attacks, it can be extremely valuable, IF Powershell has been updated and the logging configured. If you're a responder in an FTE position, then definitely push for the appropriate updates to systems, be it upgrading the Powershell installed, or upgrading the systems themselves.  When dealing with an attack, visibility is everything...you don't want the attacker moving through an obvious blind spot.

This is also really valuable for testing purposes; set up your VM, upgrade the Powershell and configure logging, and then go about testing various attacks; the FireEye instructions mentioned above refer to Mimikatz.

Powershell PSReadLine Module
One of the things that's "new" to Windows 10 is the incorporation of the PSReadLine module into Powershell v5.0, which provides a configurable command history (similar to a bash_history file).  Once everything's up and running correctly, the history file is found in the user profile at C:\Users\user\AppData\Roaming\Microsoft\Windows\PowerShell\PSReadline\ConsoleHost_history.txt.

For versions of Windows prior to 10, you can update Powershell and install the module.

This is something else I'd definitely upgrade, configure and enable in a testing environment.

CLI Tools
As someone who's written a number of CLI tools in Perl, I found this presentation by Brad Lhotsky to be pretty interesting.

Tool Listing
Speaking of tools, I recently ran across this listing of tools, and what caught my attention wasn't the listing itself as much as the format.  I like the Windows Explorer-style listing that lets you click to see what tools are listed...pretty slick.

Ransomware
I was doing some preparation for a talking I'm giving at ArchC0N in August, and was checking out the MMPC site.  The first thing I noticed was that the listing on the right-hand side of the page had 10 new malware families identified, 6 of which were ransomware.

My talk at ArchC0N is on the misconceptions of ransomware, something we saw early on in Feb and March of this year, but continue to see even now.  In an attempt to get something interesting out on the topic, a number of media sites were either adding content to their articles that had little to do with what was actually happening at a site infected with ransomware, or they were simply parroting what someone else had said.  This has let to a great deal of confusion as infection vectors for ransomware in general, as well as what occurred during specific incidents.

More on the Registry...
With respect to the Registry, there're more misconceptions that continue unabated, particularly from Microsoft.  For example, take a look at the write-up for the ThreatFin ransomware, which states:

It can create the following registry entries to ensure it runs each time you start your PC:

The write-up then goes on to identify values added to the Run key within the HKCU hive.  However, this doesn't cause the malware to run each time the system is started, but rather when that user logs into the system.