Something I've been pretty focused on in my analysis for some time is the concept of "artifact constellations".  I originally referred to this concept as "artifact clusters", but I heard someone from the FBI's Cyber BAU team use the term "constellations", and co-opted the term, in part to facilitate our conversation, but also because it sounded much more appropriate.

Artifact constellations are found as a result of events (not an event, but events) that occur on a system within close temporal proximity (another borrowed term, this one from Mr. Walters), as a result of some action, taken either by the user or threat actor.  When someone interacts with the operating system and applications, there are direct artifacts as a result of that interaction.  There are also very often indirect artifacts, created as a result of the events occurring within the "eco-system";  that is, events generated by the operating system but are not a result of direct interaction by the user.

Artifacts should never be viewed in isolation, as this can lead to incorrect findings when an artifact constellation is completed with assumption.  This can be an issue, among other instances, when examining artifacts of program execution.  For example, if an analyst were to find a prefetch file or a UserAssist entry for CCleaner, does this mean that the user executed the capabilities of CCleaner, or simply that they launched the GUI?  When viewing only artifacts such as a prefetch file or a UserAssist entry in isolation, there is qualitatively no difference between launching CCleaner and taking advantage of its full capabilities, and simply launching the CCleaner UI, waiting a few minutes, and closing the application.

Artifact constellations will vary in the number of artifacts they contain, based on a number of factors, such as the version  and configuration of the operating system, the version and configuration of installed applications, the audit configuration of the system, etc.  All of these factors play an important role in the make up of the artifact constellation, which can also be viewed as a set of "toolmarks" related to the use of the application.

The overall idea here is that rather than pursuing and basing findings on individual artifacts in isolation, we instead pursue artifact constellations, as this allows us to develop a better sense of context, as well as overcome attempts at counter-forensics, however intentional (or otherwise).

If we are used to viewing artifacts in isolation and those artifacts are not available on the system, where does that leave us?  Let's say, for example, that an analyst is familiar/comfortable with pursuing Application Prefetch files as artifacts of program execution; what happens if those artifacts don't exist on the system?  Say, the version of Windows being examined is a server variant, or the threat actor launched programs from within alternate data streams, or the threat actor took counter-forensics measures and deleted the prefetch files (and possibly disabled application prefetching).  What happens then?  How does the examiner pursue the goals of their analysis if the artifacts with which they are most comfortable no longer exist?

Attempts at counter-forensics, no matter how unintentional, should also be considered.  For example, something many analysts have seen before is an AppCompatCache entry for a possibly malicious file with a last modification time more closely aligned with the installation time of the operating system.  This can be the result of the threat actor copying the file to the system and quickly time stomping it with the $STANDARD_INFORMATION attribute time stamps from files that are part of the legitimate Windows installation.  If the analyst views this one artifact as evidence of program execution in isolation from other artifacts in the constellation, they may also make an incorrect determination as to the threat actor's dwell time.

A recent article on TheDFIRReport site regarding the Snatch ransomware describes the actions of the threat actor, which includes "turned off Windows Defender".  However, the article does not mention how the threat actor did so.  Determining the how and the when (in relation to other events) with respect to the threat actor disabling Windows Defender can be very beneficial to developing threat intelligence about that actor, and identifying toolmarks associated with their activities.

Now, there are a number of ways to disable Windows Defender, and each will have it's own artifacts or "toolmarks". We know from the article that the threat actor accesses systems via RDP, so that provides some indication as to what artifacts would be available for analysis.

One way to disable Windows Defender via the command line is to use reg.exe:

reg.exe add "HKLM\SOFTWARE\Policies\Microsoft\Windows Defender" /v
"DisableAntiSpyware" /t REG_DWORD /d "1" /f > Nul

Disabling Windows Defender can also be achieved via Powershell.  In addition to  a Registry value (or values) being modified, there will also be entries in the Powershell Event Logs indicating the usage of Powershell.  Depending upon how the commands are launched, there may also be entries in a user's Powershell console history file.

Another way to disable Defender is via a freeware tool such as Defender Control, which is a simple GUI tool with two buttons, one to disable Defender, and one to enable it.  If a threat actor uses a tool such as this, the artifact constellation will likely appear as follows:
File downloaded to/created on the systemAppCompatCache entry, and perhaps an AmCache.hve entryLaunch via user account (compromised account used to RDP into the system) results in UserAssist and RecentApps entriesThere likely won't be a Prefetch file, as workstations do not run Terminal Services by defaultRegistry values related to disabling Windows Defender modifiedWindows Defender Event Log records for event IDs 5001 and 5010Again, the constellation will vary depending upon the means used to disable Defender.  However, understanding the artifact constellation, and the toolmarks associated with various methods for disabling Defender, are not only beneficial for identifying threat actors, but can also be valuable when the threat actor has taken steps to perform counter-forensics (such as clearing Windows Event Logs).
So, why is the when important? Some ransomware variants have been observed to include a series of commands to turn Windows services off, via the 'net stop' command.  In fact, one variant was found to include more than 150 such commands, specifying several EDR, AV, and backup services. However, that variant did not include a command to disable the Windows Defender service; in that case, the threat actor had to do so manually, prior to moving their malware to the system.  In some instances, the threat actor will copy a batch file over to the system and execute it, so that they don't have to retype commands (and possibly make an error); sometimes, they leave the batch files in place when they're done.
In another instance, disabling of Windows Defender was actually determined to be a result of normal system administrator actions.  In fact, not only was Windows Defender manually disabled by administrators upon installation, but it was also regularly disabled via GPO.  It's easy to see that Defender was disabled, but determining the when can make a pretty significant difference in the incident, particularly if the analyst assumes that the threat actor disabled the application.

Conclusion
While it's very useful that there are cheat sheets available that provide us with a list of DFIR artifacts to examine, as analysts we are called upon to go beyond looking at artifacts in isolation, and instead base findings on artifact constellations.  Doing so also allows us to develop toolmarks associated with specific sets of activities, providing context and allowing us to better understand that threat actors.  It's easy to say that some event (Windows Defender was disabled) occurred, but developing the how and the when of that event provides the context to better visualize a threat actor's activities.

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.

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.