Forensic Blogs

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.