Book Update
I recently and quite literally stumbled across an image online that was provided as part of a challenge, involving a compromised system. I contacted the author, as well as discussed the idea of updating the book with my tech editor, and the result of both conversations is that I will be extending the book with an additional chapter. This image is from a Windows 2008 web server that had been "compromised", and I thought it would be great to add this to the book, given the types of "cases" that were already being covered in the book.
RDP Bitmap Cache Parser
I ran across this French web site recently, and after having Google translate it for me, got a bit better view into what went into the RDP bitmap cache parsing tool. This is a pretty fascinating idea; I know that I've run across a number of cases involving the use of RDP, either by an intruder or a malicious insider, and there could have been valuable clues left behind in the bitmap cache file.
Pancake Viewer
I learned from David Dym recently that Matt (works with David Cowen) is working on something called the "pancake viewer", which is as DFVFS-backed image viewer using wxPython for the GUI. This looks like a fascinating project, and something that will likely have considerable use, particularly as the "future functionality" is added.
Web Shells
Web shells are nothing new; here is a Security Disclosures blog post regarding web shells from 3 years ago. What's "new" is what is has recently been shared on the topic of web shells.
This DFIR.IT blog post provides some references (at the bottom of the post) where other firms have discussed the use of web shells, and this post on the SecureWorks site provides insight as to how a web shell was used as a mechanism to deploy ransomware.
This DFIR.IT blog post (#3 in the series) provides a review of tools used to detect web shells.
A useful resource for Yara rules used to detect web shells includes this one by 1aNOrmus.
Sunday, July 17, 2016
Wednesday, July 06, 2016
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.
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.
Subscribe to:
Posts (Atom)