RegRipper
Not all RegRipper plugins come from external sources; in fact, a good number of the plugins I've written start as something I've run across on the Internet, from various sources (most times Twitter). Sometimes it's a blog post, other times it's a malware write-up, or it could be the result of a working a forensic challenge.
Based on Adam's post, I created a plugin (named wsh_settings.pl) that outputs the values of the Settings key, and includes an Analysis Tip that references the Remote value.
I also updated the clsid.pl plugin to incorporate looking for the TreatAs value. On a sample hive that I have from a Win7 SP1 system, I ran the following command:
rip -r d:\cases\test\software -p clsid | find "TreatAs"
I got a total of 9 hits, 7 of which were all for the same GUID (i.e., {F20DA720-C02F-11CE-927B-0800095AE340}), which appears to refer to packager.dll.
I also created a TLN output version of clsid.pl (named clsid_tln.pl) so that this information can be used to create timeline (in and of itself), or can be added to a timeline that incorporates other data sources. I know from initial testing that under "normal" circumstances, the LastWrite times for the keys may be lumped together around the same time, but what we're looking for here is outliers, timeline entries that correspond with other suspicious activity, forming an artifact cluster.
Book
I received an email from my publisher on 20 Aug 2018 telling me that Investigating Windows Systems had officially been published, and is available here through the publisher! I'm not sure what that means with respect to the book actually being available or shipped (if you pre-ordered it) from Amazon; for me, it's a milestone, something I can mark off my list. That's #9 down (as in, nine books that I've authored), and I'm currently working on Practical Windows Investigations, which will is due out next year.
IWS is a bit of a departure from my previous books; instead of listing various artifacts that you could use in an investigation, and leaving it to the reader to figure out how to string them together, I used images available online to illustrate what an investigation might look like. Using the images, I provide analysis goals that are more inline with what one might expect to see during a real world IR investigation. I then walk through the analysis of the image (based on the stated goals), providing decision pivot points along the way. However, these investigations are somewhat naturally limited...they aren't enterprise level, don't involve things like lateral movement, etc. As such, these things aren't addressed, but I did try to cover as much as I could with what was available.
I have a GitHub repo for the book - it doesn't contain a great deal at the moment, just links to the images used, and in the folder for chapter 4, code that I wrote for that particular chapter. I'm sure I'll be adding material over time, either based on requests or based on interesting things from my notes and folders for the book.
Practical Windows Investigations is going to swing the pendulum back a bit, so to speak, in that rather than just looking at artifacts, I'm focusing on different aspects of investigations and addressing what can be achieved when pursuing those avenues. The book is currently spec'd at 12 chapters, and the list is not too different from what was listed in this post from March.
The current chapters are:
Core Concepts
How to analyze Windows Event Logs
How to get the most out of RegRipper
Malware Detection
How to determine data exfiltration
File (LNK, DOCX/DOC, PDF) Analysis
How to investigate lateral movement
How to investigate program execution
How to investigate user activity
How to correlate/associate a device with a user (USB, Bluetooth)
How to detect/analyze the use of anti-forensics
Making use of VSCs
As with my previous books, tools used for analysis will be free and open source tools; this is due to the fact that I simply do not have access to commercial tools. This is a topic that is continually brought up during prospectus reviews, and the reviewers simply do not seem to understand.
Updates
Win10 Notification Database
Leave it to MS to make our jobs as DFIR analysts fun, all day, every day! Actually, that is one of the things I've always found fascinating about analyzing Windows systems is that the version of Windows, more often than not, will predicate how far you're able to go with your analysis.
An interesting artifact that's available on Win10 systems is the notification database, which is where those pop up messages you receive on the desktop are stored. Over the past couple of months, I've noticed that on my work computer, I get more of these messages, because it now ties into Outlook. It turns out that this database is a SQLite database. Lots of folks in the community use various means to parse SQLite databases; one of the popular ways to do this is via Python, and subsequently, you can often find either samples via tutorials, or full-on scripts to parse these databases for you.
MalwareMaloney posted a very interesting article on parsing the write-ahead logging (.wal) file for the database. Also, as David pointed out,
Anytime you're working with a SQLite database, you should consider taking a look at Mari's blog post on recovering deleted data.
RegRipper
Based on input from a user, I updated the sizes.pl plugin in a way that you may find useful; it now displays a brief sample of the data 'found' by the plugin (default is 48 bytes/characters). So, instead of just finding a value of a certain size (or above) and telling you that it found it, the plugin now displays a portion of the data itself. The method of display is based on the data type...if it's a string, it outputs a portion of the string, and if the data is binary, it outputs of hex dump of the pre-determined length. That length, as well as the minimum data size, can be modified by opening the plugin in Notepad (or any other editor) and modifying the "$output_size" and "$min_size" values, respectively.
Here is some sample output from the plugin, run against a Software hive known to contain a malicious Powershell script:
sizes v.20180817
(All) Scans a hive file looking for binary value data of a min size (5000)
Key : \4MX64uqR Value: Dp8m09KD Size: 7056 bytes
Data Sample (first 48 bytes) : aQBmACgAWwBJAG4AdABQAHQAcgBdADoAOgBTAGkAegBlACAA...
From here, I'd definitely pivot on the key name ("4MX64uqR"), looking into a timeline, as well as searching other locations in the Registry (auto start locations??) and file system for references to the name.
Interestingly enough, while working on updating this plugin, I referred back to pg 34 of Windows Registry Forensics and for the table of value types. Good thing I keep my copy handy for just this sort of emergency. ;-)
Mari has an excellent example of how she has used this plugin in actual analysis here.
IWS
Speaking of books, Investigating Windows Systems is due out soon. I'm really looking forward to this one, as it's a different approach all together from my previous books. Rather than listing the various artifacts that are available on Windows systems, folks like Phill Moore, David Cowen and Ali Al-Shemery graciously allowed me access to the images that they put together so that I could work through them. The purpose of the book is to illustrate a way of stringing the various artifacts together in to a full-blown investigation, with analysis decisions called out and discussed along the way.
What I wanted to do with the book is present something more of a "real world" analysis approach. Some of the images came with 30 or more questions that had to be answered as part of the challenge, and in my limited experience, that seemed a bit much.
The Github repo for the book has links to the images used, and for one chapter, has the code I used to complete a task. Over time, I may add other bits and pieces of information, as well.
OSDFCon
My submission for OSDFCon was accepted, so I'll be at the conference to talk about RegRipper, and how you can really get the most out of it.
Here is the list of speakers at the conference...I'm thinking that my speaker bio had something to do with me being selected. ;-)
Leave it to MS to make our jobs as DFIR analysts fun, all day, every day! Actually, that is one of the things I've always found fascinating about analyzing Windows systems is that the version of Windows, more often than not, will predicate how far you're able to go with your analysis.
An interesting artifact that's available on Win10 systems is the notification database, which is where those pop up messages you receive on the desktop are stored. Over the past couple of months, I've noticed that on my work computer, I get more of these messages, because it now ties into Outlook. It turns out that this database is a SQLite database. Lots of folks in the community use various means to parse SQLite databases; one of the popular ways to do this is via Python, and subsequently, you can often find either samples via tutorials, or full-on scripts to parse these databases for you.
MalwareMaloney posted a very interesting article on parsing the write-ahead logging (.wal) file for the database. Also, as David pointed out,
Anytime you're working with a SQLite database, you should consider taking a look at Mari's blog post on recovering deleted data.
RegRipper
Based on input from a user, I updated the sizes.pl plugin in a way that you may find useful; it now displays a brief sample of the data 'found' by the plugin (default is 48 bytes/characters). So, instead of just finding a value of a certain size (or above) and telling you that it found it, the plugin now displays a portion of the data itself. The method of display is based on the data type...if it's a string, it outputs a portion of the string, and if the data is binary, it outputs of hex dump of the pre-determined length. That length, as well as the minimum data size, can be modified by opening the plugin in Notepad (or any other editor) and modifying the "$output_size" and "$min_size" values, respectively.
Here is some sample output from the plugin, run against a Software hive known to contain a malicious Powershell script:
sizes v.20180817
(All) Scans a hive file looking for binary value data of a min size (5000)
Key : \4MX64uqR Value: Dp8m09KD Size: 7056 bytes
Data Sample (first 48 bytes) : aQBmACgAWwBJAG4AdABQAHQAcgBdADoAOgBTAGkAegBlACAA...
From here, I'd definitely pivot on the key name ("4MX64uqR"), looking into a timeline, as well as searching other locations in the Registry (auto start locations??) and file system for references to the name.
Interestingly enough, while working on updating this plugin, I referred back to pg 34 of Windows Registry Forensics and for the table of value types. Good thing I keep my copy handy for just this sort of emergency. ;-)
Mari has an excellent example of how she has used this plugin in actual analysis here.
IWS
Speaking of books, Investigating Windows Systems is due out soon. I'm really looking forward to this one, as it's a different approach all together from my previous books. Rather than listing the various artifacts that are available on Windows systems, folks like Phill Moore, David Cowen and Ali Al-Shemery graciously allowed me access to the images that they put together so that I could work through them. The purpose of the book is to illustrate a way of stringing the various artifacts together in to a full-blown investigation, with analysis decisions called out and discussed along the way.
What I wanted to do with the book is present something more of a "real world" analysis approach. Some of the images came with 30 or more questions that had to be answered as part of the challenge, and in my limited experience, that seemed a bit much.
The Github repo for the book has links to the images used, and for one chapter, has the code I used to complete a task. Over time, I may add other bits and pieces of information, as well.
OSDFCon
My submission for OSDFCon was accepted, so I'll be at the conference to talk about RegRipper, and how you can really get the most out of it.
Here is the list of speakers at the conference...I'm thinking that my speaker bio had something to do with me being selected. ;-)
Gaps and Up-Hill Battles
I've been thinking about writing a RegRipper plugin that looks for settings that indicate certain functionality in Windows has been disabled, such as maintaining JumpLists, as well as MRUs in the Registry.
Hold on for a segue...
David Cowen recently requested input via his blog, regarding the use of anti-forensics tools seen in the wild. A little more than two years ago, Kevin S. wrote this really awesome blog post regarding the evolution of the Samas/Samsam ransomware, and I know you're going to ask, "great, but what does this have to do with anti-forensics tools?" Well, about half way down the post, you'll see where Kevin mentions that one of the early variants of Samas included a copy of sdelete in one of its resource sections.
As usual, Brett made some very poignant comments, in this case regarding seeing anti- or counter-forensics tools in the wild; specifically, just having the program on a system doesn't mean it was used, and with limited visibility, it's difficult to see how it was used.
Now, coming back around...
What constitutes counter-forensics efforts, particularly when it comes to user intent? Do we really know the difference between user intent and operating system/application functionality? Maybe more importantly, do we know that there is such a thing?
I've seen too many times where leaps (assumptions, speculation) have been made without first fully examining the available data, or even just looking a little bit closer. Back in the days of XP, an issue I ran into was an empty Recycle Bin for a user, which might have been a bad thing, particularly following a legal hold. So, an analyst would preview an image, find an empty Recycle Bin, and assume that the user had emptied it, following the legal hold announcement. But wait...what was the NukeOnDelete setting? Wait...the what? Yes, with this functionality enabled, the user would delete a file as they normally would, but the file would not appear in the Recycle Bin.
Other functionality that's similar to this includes, did the user clear the IE history, or was it the result of the regularly scheduled purge? Did the user delete files and run defrag after a legal hold order, or was defrag run automatically by the OS?
Skipping ahead to modern times, what happens if you get a "violation of acceptable use policies" case, or a harassment case, or any other case where user activity is a (or the) central focus of your examination, and the user has no JumpLists. Yes, the automatic JumpLists folder is empty. Does that seem possible? Or did the user suspect someone would be looking at their system, and purposely delete them? Well, did you check if the tracking of JumpLists had been disabled via the Registry?
My point is that there is functionality within Windows to disable the recording and maintenance of various artifacts that analysts use to do their jobs. This functionality can be enabled or disabled through the Registry. As such, if an analyst does not find what they expect to find (i.e., files in the Recycle Bin, RecentDocs populated, etc.) then it's a good idea to check for the settings.
Oh, and yes, I did write the plugin, the current iteration of which is called disablemru.pl. I'll keep adding to it as more information becomes available.
Hold on for a segue...
David Cowen recently requested input via his blog, regarding the use of anti-forensics tools seen in the wild. A little more than two years ago, Kevin S. wrote this really awesome blog post regarding the evolution of the Samas/Samsam ransomware, and I know you're going to ask, "great, but what does this have to do with anti-forensics tools?" Well, about half way down the post, you'll see where Kevin mentions that one of the early variants of Samas included a copy of sdelete in one of its resource sections.
As usual, Brett made some very poignant comments, in this case regarding seeing anti- or counter-forensics tools in the wild; specifically, just having the program on a system doesn't mean it was used, and with limited visibility, it's difficult to see how it was used.
Now, coming back around...
What constitutes counter-forensics efforts, particularly when it comes to user intent? Do we really know the difference between user intent and operating system/application functionality? Maybe more importantly, do we know that there is such a thing?
I've seen too many times where leaps (assumptions, speculation) have been made without first fully examining the available data, or even just looking a little bit closer. Back in the days of XP, an issue I ran into was an empty Recycle Bin for a user, which might have been a bad thing, particularly following a legal hold. So, an analyst would preview an image, find an empty Recycle Bin, and assume that the user had emptied it, following the legal hold announcement. But wait...what was the NukeOnDelete setting? Wait...the what? Yes, with this functionality enabled, the user would delete a file as they normally would, but the file would not appear in the Recycle Bin.
Other functionality that's similar to this includes, did the user clear the IE history, or was it the result of the regularly scheduled purge? Did the user delete files and run defrag after a legal hold order, or was defrag run automatically by the OS?
Skipping ahead to modern times, what happens if you get a "violation of acceptable use policies" case, or a harassment case, or any other case where user activity is a (or the) central focus of your examination, and the user has no JumpLists. Yes, the automatic JumpLists folder is empty. Does that seem possible? Or did the user suspect someone would be looking at their system, and purposely delete them? Well, did you check if the tracking of JumpLists had been disabled via the Registry?
My point is that there is functionality within Windows to disable the recording and maintenance of various artifacts that analysts use to do their jobs. This functionality can be enabled or disabled through the Registry. As such, if an analyst does not find what they expect to find (i.e., files in the Recycle Bin, RecentDocs populated, etc.) then it's a good idea to check for the settings.
Oh, and yes, I did write the plugin, the current iteration of which is called disablemru.pl. I'll keep adding to it as more information becomes available.
- « Previous Page
- 1
- 2
- 3
- 4
- 5
- …
- 56
- Next Page »