These plugins were developed as a result of this article posted to Medium by Zach, aka, "svch0st". The article is fascinating, in that Zach found that there're Registry keys that appear to track the applications that access the microphone and webcam on a Windows system. In addition, there are values that specify the last start and stop times for the applications using those devices. Zach then takes the article a step further by illustrating what it looks like when a RAT is used to access and record audio from the mic.
Running the consentstore.pl plugin against a hive extracted from one of my own systems, I can see the following:
microphone
C:#Users#harlan#AppData#Roaming#Zoom#bin#Zoom.exe
LastWrite time 2020-05-05 23:06:16Z
LastUsedTimeStart 2020-05-05 23:00:52Z
LastUsedTimeStop 2020-05-05 23:06:16Z
webcam
C:#Users#harlan#AppData#Roaming#Zoom#bin#Zoom.exe
LastWrite time 2020-05-05 23:05:24Z
LastUsedTimeStart 2020-05-05 23:01:30Z
LastUsedTimeStop 2020-05-05 23:05:24Z
As you can see from the above information, the key LastWrite times correspond to the final time stamp, or the "LastUsedTimeStop".
The consentstore_tln.pl plugin outputs the same information in the 5-field TLN format, illustrated
1588719652|REG|||ConsentStore microphone "C:\Users\harlan\AppData\Roaming\Zoom\bin\Zoom.exe" LastUsedTimeStart
1588719976|REG|||ConsentStore microphone "C:\Users\harlan\AppData\Roaming\Zoom\bin\Zoom.exe" LastUsedTimeStop
1588719690|REG|||ConsentStore webcam "C:\Users\harlan\AppData\Roaming\Zoom\bin\Zoom.exe" LastUsedTimeStart
1588719924|REG|||ConsentStore webcam "C:\Users\harlan\AppData\Roaming\Zoom\bin\Zoom.exe" LastUsedTimeStop
Because the full name of the key is included in the timeline output, albeit with the "#" translated to back slashes, searches run across the timeline looking for pivot points (such as AppCompatCache or AmCache entries, user profile paths, etc.) will result in positive 'hits'. For example, in Zach's article, the RAT used to access the microphone was found in the path "dev\shell.exe". If an analyst found an entry for "dev\shell.exe" in the AppCompatCache or AmCache data, and then using that as a pivot point found something similar to the above, the analyst would not only have the insight that the file was on the system, but also what it had been used for. As such, this also serves to extend the "program execution" artifact category a bit, because know we not only know that the file was executed, but we now also have insight into what it was used for, or what it did.
In addition, this information provides us with some very useful artifacts, particularly when viewed as part of an overall artifact constellation. For example, this provides a view into "humanness", or indications of human interaction with the system. I most instances when engaging with applications such as Zoom, the user has an option to use the mic and webcam on the local system, and has to click a button/make a choice to do so.
Further, as this is a "new" location of sorts, it is not yet covered/addressed by counter-forensics techniques. From the above information retrieved from the Software hive, we can see that Zoom was launched from the user's profile path, and the dates and times that it ran, providing insight into user activity in the face of counter-forensics activities, even the entire user profile being deleted.
So, thanks to Zach for sharing the information, and providing the opportunity for me to view this information and create these two plugins. Keep up the great work, Zach, and I'm going to keep watching to see what further topics you tackle.
AppCompatFlags
Not a new plugin, but I updated the appcompatflags.pl plugin based on the content provided by Christopher at TrustedSec, which looks like the AppCompatFlags key is another useful persistence location.
The Windows Incident Response Blog is dedicated to the myriad information surrounding and inherent to the topics of IR and digital analysis of Windows systems. This blog provides information in support of my books; "Windows Forensic Analysis" (1st thru 4th editions), "Windows Registry Forensics", as well as the book I co-authored with Cory Altheide, "Digital Forensics with Open Source Tools".
Sunday, June 14, 2020
Plugin Spotlight - printer_settings, featureusage
Given the number of RegRipper plugins that are part of the distro, I thought it would be a good idea every now and then to spotlight a plugin or two, and share what led to the plugin being created, and discuss how it can be used as part of analysis.
printer_settings.pl
This plugin is a result of what I read about Project TajMahal. If you scroll down in Appendix II, to modules 65 and 66, you'll see the following statement:
Steals printed documents from spooler queue.
This is done by enabling the “KeepPrintedJobs” attribute for each (or just one) configured printer stored in Windows Registry. What this means is that print jobs will not be deleted once they're complete; as such, this serves as an interesting means of data collection, specifically, data from information repositories.
I thought that was interesting and tried setting the attribute via the UI, and then writing and testing a plugin to detect the attribute setting. The result is the plugin.
So, how would you use this during an engagement? A positive finding from the plugin would be a pivot point into deeper analysis; for example, if the attribute is set, what is the LastWrite time of the key (or keys) in question? Does this time stamp then prove to be a useful pivot point within the greater context of an overall system timeline? If you have an image of the system, what is the content of the spooler?
featureusage.pl
CrowdStrike recently posted an article on the various values and subkeys beneath the FeatureUsage key, so I'm not sure what I could add to that.
In short, the FeatureUsage artifacts reportedly serve as evidence of program execution, on Windows 10 version 1903 and higher. The CrowdStrike blog post provides some very good information regarding the subkey contents; what really stood out for me is how the contents provide insight into humanness within the Windows Registry, as well as provide information that analysts can look to in the face of counter-forensics.
printer_settings.pl
This plugin is a result of what I read about Project TajMahal. If you scroll down in Appendix II, to modules 65 and 66, you'll see the following statement:
Steals printed documents from spooler queue.
This is done by enabling the “KeepPrintedJobs” attribute for each (or just one) configured printer stored in Windows Registry. What this means is that print jobs will not be deleted once they're complete; as such, this serves as an interesting means of data collection, specifically, data from information repositories.
I thought that was interesting and tried setting the attribute via the UI, and then writing and testing a plugin to detect the attribute setting. The result is the plugin.
So, how would you use this during an engagement? A positive finding from the plugin would be a pivot point into deeper analysis; for example, if the attribute is set, what is the LastWrite time of the key (or keys) in question? Does this time stamp then prove to be a useful pivot point within the greater context of an overall system timeline? If you have an image of the system, what is the content of the spooler?
featureusage.pl
CrowdStrike recently posted an article on the various values and subkeys beneath the FeatureUsage key, so I'm not sure what I could add to that.
In short, the FeatureUsage artifacts reportedly serve as evidence of program execution, on Windows 10 version 1903 and higher. The CrowdStrike blog post provides some very good information regarding the subkey contents; what really stood out for me is how the contents provide insight into humanness within the Windows Registry, as well as provide information that analysts can look to in the face of counter-forensics.
Subscribe to:
Posts (Atom)