Root Cause Analysis

One of the challenges within DFIR, particularly as we've moved to an enterprise approach by leveraging EDR telemetry, is the root cause analysis, or "RCA". In short, the challenge is observing malicious activity and determining the root cause; the challenge itself stems from the fact that EDR telemetry is only partial visibility, or that correlating observed malicious activity with causal data not evident or available via EDR telemetry requires additional context, and by extension, additional effort/expenditure of resources. It also requires an additional "leveling up" of skillsets. 

Yes, many organizations that deploy EDR tooling also include a means for extracting additional files/data from the endpoint, and what to collect isn't usually in question. Rather, how to truly exploit the collected data is the issue, with the exploitation of that data being the "levelling up".

When malicious activity is observed, or the impact of malicious activity is discovered (via threat hunting, etc.), the challenge then becomes, how do we determine the root cause? In the past, when someone has shared suspicious activity with me and sought guidance as to next steps, I've often asked, "...did a reboot or login occur just prior to the activity?" as a means of developing context around the observed activity. Was the executable launched via an auto-start mechanism, such as a Windows service, entry in a Run key, or as a Scheduled Task? The thought process has been to seek causal events for the observed activity, which can be important to not only determine the root cause, but perhaps to also identify a shift in TTPs, once we're to a point where we can arrive at attribution.

There are a lot of different ways for threat actors to persist on Windows systems, some of which were mentioned earlier in this post. Each has their advantages and disadvantages, and both require and provide different levels of access. For example, creating an entry in the user's Run key means that the malware won't start again until the user logs in, and then runs within the user context. However, if the threat actor has Admin privileges, they can create a Windows service or Scheduled Task, which then will run malware with SYSTEM level privileges. As a result, the persistence mechanism used provides a great deal of context beyond just the entry for the malware. 

To provide further insight into this topic, Krz wrote up an excellent blog post not long ago about how a laptop going on battery (unplugged from the power cord) can impact an investigation.

Based on the MITRE "Event Triggered Execution: Screensaver" page, I created a RegRipper plugin for my local repo to parse the screensaver settings out of the NTUSER.DAT hive, and ran it against a hive extracted from my local system, the output of which follows:

Launching screensaver v.20220427
screensaver v.20220427
(NTUSER.DAT) Gets user's screensaver settings
MITRE: T1546.002 (persistence)

Control Panel\Desktop
LastWrite: 2021-11-29 11:53:45Z

Screensaver is active.
SCRNSAVE.exe value not found.

Analysis Tip: Threat actors have been observed using the screen saver as a persistent mechanism.

Ref: https://cocomelonc.github.io/tutorial/2022/04/26/malware-pers-2.html

Now, if the "SCRNSAVE.exe" value (listed above as "not found") was set to something that it shouldn't be, we could then use the Desktop key LastWrite time as a pivot point for further analysis. As the Desktop value contains a number of values, we may not be able to specifically attribute the addition or alteration of the SCRNSAVE.exe value to the modification of the key LastWrite time, but it does provide us with some information we can pivot on and leverage in our analysis. 

Another instance to make clear why this example is so compelling...see Jorge's tweet here, which points us to Wietze's tweet, which in turn points us to a new #LOLBAS. Kind of a circuitous route (also apparently available as far back as 2001, from here), I know, but ultimately what this leads us to is the use of a Control Panel applet (desktop.cpl) to proxy the execution of arbitrary commands. In the example, 'calc.exe' is renamed to 'calc.scr' and launched by calling the "InstallScreenSaver" function of the applet. As a result, this persistence mechanism can be established via reg.exe or rundll32.exe; different command lines with different impacts on the system (re: artifacts associated with their execution) but both achieve the same result.

Further, we now have insight into the level of access achieved by the threat actor, the context under which the malware will run, and when the malware is expected to run. This also provides insights into the sophistication and intent of the threat actor, and can be applied toward attribution.

File Formats

Having an understanding of file formats is an important factor in DFIR work. In particular, analysts should understand what a proper file using a particular format should look like, so that they can see when something is amiss, or when the file itself has been manipulated in some manner.

Understanding file formats  goes well beyond understanding PE file formats and malware RE. Very often, various Microsoft file formats include data, or metadata (defined as "data about data") that can be mined/parsed, and then leveraged to tremendous effect, furthering overall analysis and intelligence development, often across multiple cases and campaigns.

LNK
Windows shortcut, or LNK files, have been covered extensively in this blog, as well as other blogs, in addition to having been well documented by MS. Suffice to say, LNK files can be leveraged by both good guys and bad guys, and if bad guys leverage them, so should the good guys...after all, the bad guys sending you an LNK file created in their environment is essentially just "free money", particularly if you're in CTI.

For example, the GOLDBACKDOOR report shows us a threat actor that sends an LNK file to their target, in a zip archive. So, the threat actor develops the LNK file in their environment, and sends that LNK file with all of it's metadata to the target. Now, as a DFIR analyst, you may have a copy of a file created within the threat actor's environment, one that contains information about their system(s). Why not take advantage of that metadata to develop a more meaningful threat intel picture?

Analysis of LNK files is similar to being an EOD tech (I would imagine)...you're looking at the construction of a "device", noting production mechanisms (based on tooling) as well as unique items that allow you to tie or "attribute" the LNK file in some manner. You can then leverage sites such as VirusTotal (via a retro-hunt) and populate your own MISP instance to build out a larger, more contextual threat intelligence picture. For example, consider the LNK file delivered as part of the Quantum ransomware campaign discussed in this TheDFIRReport article; the article provides an image of the metadata extracted from the LNK file. The machine ID, MAC address, and volume serial number (not shown) could be put into a Yara rule and submitted as a VirusTotal retro-hunt, providing insight into other instances or campaigns were LNK files with the same values were employed. You can also tighten or loosen the aperture of your retro-hunt by adding or removing values within the Yara rule.

Yet another example of how LNK metadata can be used...and likely the best example of this sort of data exploitation available thus far...can be seen in this Mandiant blog post from 2018. The post addresses differences between APT29 campaigns from 2016 and 2018, with references to differences in LNK files shows in figures 5 and 6. Reading through the article, you can see where the Mandiant team leveraged the data they had available to develop insights about the actor's campaigns.

OLE
OLE, or "object linking and embedding" (aka, "structured storage") is a file format most often associated with older versions of MS Office. As such, when MS transitioned the world to the "new" MSOffice file format, many likely thought, "okay, I'll never see that file format again." Oh, how wrong we were! The OLE format is used within a number of other files, including:

Files
Automatic JumpLists - all but one embedded stream consists of an LNK "file"
MSI files
Sticky Notes
Other files, some of which are application-dependent

We can look to a variety of tools to meet our needs in parsing these files:

OLE Parsing Tools
olefile
MiTeC SSV
ripOLE

For specifically parsing/working with MSI files, I'm told that folks use tools such as InstEdit, and orca.exe from MS.

Metadata that may be present in the document structure can be leveraged or exploited in a manner similar to LNK files, or better yet, really leveraged by combining it with what's found in LNK files. For example, the LNK file in the GOLDBACKDOOR report reportedly downloads a decoy .doc file, meaning that the metadata from the LNK file has a direct link to the metadata found in the .doc file.

Registry
At this point, the Windows Registry file format is well-understood, and documented (here, by Maxim Suhanov). As a result, we know how to parse it, but much like other file structures, we (as a community and industry) regularly fall short in truly exploiting the file format to our advantage. 

Registry keys have embedded time stamps, which as Lina L. astutely and articulately described in her blog post, can be manipulated. Time stamps are also visible in value data (albeit NOT in the structure of values) as strings, as binary data, or embedded within binary data streams. All of these can be used to further analysis, including possibly even to identify key LastWrite time manipulation (very much depending upon how it's done).

For example, a recent TheDFIRReport write-up on the Quantum ransomware indicates that when the user double-clicks the ISO file, artifacts of the ISO file being mounted on the system appear in the Windows Event Log. Okay, great...but does the drive letter assignment also appear in the MountedDevices key in the System hive? When the user double-clicks the LNK file embedded in the ISO file, is that action reflected in the user's UserAssist key?

Aside from the "normal" Registry hive files we're all familiar with...Software, System, SAM, Security, NTUSER.DAT, USRCLASS.DAT...other files on the system follow the same file format. This means that all of the tools we use to parse the 'usual suspects' can also be leveraged against these other files, which include BBI, DEFAULT, and ELAM in the system32\config folder, the AmCache.hve file, and the settings.dat files associated with MS Store apps (i.e., in the %user%\AppData\Local\Packages\windows.immersivecontrolpanel_cw5n1h2txyewy\Settings folder, etc.)

Tools
In 2008, Jolanta Thomassen created the tool regslack.pl, to parse deleted data from hive files as part of her thesis work. Since then additional tools have been created for parsing this information, not the least of which includes the del.pl and slack.pl RegRipper plugins. 

LNK (Ab)use

I've discussed LNK files a number of times in this blog, and to be honest, I really don't think that this is a subject that gets the attention it deserves. In my experience, and I humbly bow to collection bias here, LNK files are not as well understood as they (sh|c)ould be in the DFIR and CTI fields, which puts defenders at a disadvantage. When I suggest that LNK files aren't really well understood by DFIR and CTI teams, I'm basing that on my own experience with multiple such teams over the years, largely the result of direct interaction.

Why is that? Well, the LNK file format is well documented at the MS site, and there have been a number of tools written over the years for parsing these files. I've even gone so far as to create the smallest functioning LNK file, based on the minimum functional requirements, and with all of the metadata zero'd out or altered. However, IMHO, the real issue is that the actual functional, operational use of these files is not discussed often enough, and as such, they fall out of scope, much like other aspects of Windows systems (Ex: NTFS alternate data streams (ADSs)). As such, LNK files are not something that is closely examined during DFIR or proactive threat hunting engagements, and even more rarely do they appear in reporting. Finally, as effective as these files can be, they simply are not the "new shiny hotness"...they aren't 0-days, and they aren't the newest, hottest exploits. As a result, not a lot of focus and attention are given to these files, and it's likely that their use is less evident than might otherwise be the case.

V3ded's Github repo includes an article that does a great job of covering how LNK files can be abused. While the title refers to "initial access", it seems to describe the use of document macros to create an LNK file, rather than "weaponized" LNK files being delivered to a target. The difference is an important one...using macros (or some other method) to create LNK files on a target system means that the LNK file metadata is going to be specific to the target system itself. Alternatively, an LNK file delivered to the target is going to contain metadata specific to the threat actor's dev environment.

V3ded's article refers to a couple of means of persistence that are very interesting. One is the use of shortcut keys, defined within the structure of the LNK file. Per the article, an LNK file can be placed on the desktop and structured to be activated by a specific and common key sequence, such as Control+C (copy), Control+V (paste), or some other commonly used sequence. Another means of persistence involves the use of the "iconfilename" element within the LNK file structure; by pointing to an icon file located on a remote, TA-controlled system, attempts to access the resource (via activation of the LNK file) will involve authentication, allowing the threat actor to collect password hashes. What's interesting about both of these techniques is that neither one requires the threat actor to authenticate to collect information and gain access to your systems. This means that following containment and eradication steps, when you think you've ejected the threat actor and you've changed passwords in your environment, the threat actor is still able to collect information that may allow them to re-enter your environment. 

Again, when LNK files are sent to a target, from a threat actor, those files will contain metadata specific to the threat actor's dev environment. For example, consider MalwareByte's analysis of an "LNK attack" tied to a threat actor group referred to as "Higaisa". This attack apparently involved an LNK file being sent to the target in a zip archive; the LNK file would have to have been developed by the threat actor, and the file metadata would provide insight into the threat actor's development environment. 

A similar example could be seen in Mandiant's analysis CozyBear phishing campaigns. In this example, the Mandiant team did an excellent job leveraging LNK files, and looked specifically at differences between successive campaigns to derive insights into the threat actor's evolution.

Over time, we've also seen LNK files sent or linked to a target while embedded in ISO or IMG file formats, allowing them to bypass MOTW (re: ADS) restrictions. In cases such as this, the metadata within the LNK file structure can provide insights as to the build or production method, proliferation of build methods, etc., similar to the way EOD professionals look to toolmarks and artifacts to identify bombmakers. As such, these resources should not be ignored by DFIR and CTI professionals, but should instead be leveraged for a range of insight. For example, Yara rules can be used to perform retro-hunts via VirusTotal to look for the use and proliferation of specific platforms, as well as view changes in LNK file production techniques between campaigns, or simply over time. Tools can be designed to comb through specific locations within Windows systems (or images), scanning for persistence techniques and other anomalies, automatically providing them for analysis and development into retro-hunts.

Digging Into Open Reporting

As many readers of this blog are aware, I often find great value in open reporting, but that I also see the value in taking that open reporting a step (or three) further beyond where it exists now. In more than a few instances, something extra can be pulled from open reporting, something not presented or discussed in the article that can be of significant value to readers in domains such as DFIR, detection engineering, MSS/SOC monitoring, etc. As a result, I've spent a great deal of time during my career looking for alternate means for detecting activity (user, threat actor, malware) presented in open reporting, largely due to gaps in that reporting.

For example, there's a great deal of open reporting that is based solely on RE and analysis of malware that is part of the final stage of the attack (ransomware, etc.), without addressing anything that occurred prior to the final malware deployment, beginning with initial access. Now, I understand that not everyone has access to DFIR data to support this level of open reporting, but some do, and tremendous value can be derived if that information is shared. I understand that in some instances, authors feel that they can't share the information but very often it may simply be that they don't see the value in doing so.

MS DART and MSTIC recently published some excellent open reporting on Tarrask that I found quite fascinating, based initially on the title alone (which, oddly enough, is what also catches my eye with respect to beers and books). I mean, the title refers to using Scheduled Tasks for defense evasion...when I read that, I immediately wanted to know more, and I have to say, the DART and MSTIC teams did not disappoint. 

The article itself is full of "stuff" that can be unpacked. For example, there were some interesting statements in the article, such as:

Further investigation reveals forensic artifacts of the usage of Impacket tooling for lateral movement and execution...

So, what does that look like? I searched on the web and found that someone shared some forensic artifacts associated with the use of Impacket tooling about 2 yrs ago. While this is a great resource, unfortunately, many of the Windows Event Log records described are not available via the default logging configuration and require additional steps to set up. For example, while generating Security-Auditing records with event ID 4688 is just a matter of enabling Process Tracking, including the full command line for the process in the event record requires an additional Registry modification. Throughout my time in DFIR, there have been very few instances where the audit configuration of compromised systems was beyond default, and more than a few instances where threat actors took steps to disable the logging that was available.

Note that the article has a similar comment to that effect:

Neither of these are audited by default and must be explicitly turned on by an administrator. 

Ah, there you go! There are these great Windows Event Log artifacts that are available if the default audit configuration is modified prior to an attack taking place! 

Note: Even after an attack starts, there are ways to manipulate Windows Event Logs as a means of defense evasion. This is NOT part of the MS DART/MSTIC blog post, and is mentioned here to bring attention to issues with default audit configuration and monitoring systems for modifications to the audit configuration.

From the guidance section of the article:

Enumerate your Windows environment registry hives looking in the HKLM\SOFTWARE\Microsoft\Windows NT\CurrentVersion\Schedule\TaskCache\Tree registry hive and identify any scheduled tasks without SD (security descriptor) Value within the Task Key...

Issues with nomenclature aside, this is pretty solid advice. Not having access to proactive threat hunting, I opted to create a simple RegRipper plugin for use in DFIR analysis and hunting. Actively threat hunting across endpoints in your environment for the same condition is a great way to go about detecting such things much earlier in the attack cycle. 

Something else to unpack from all of this is that, per the article, SYSTEM level privileges are required in order to remove the "SD" value from the Registry on a live, running system. As such, the threat actor first needs to access the system, and then escalate privileges...both of which provide opportunities for detection. If such activity is detected and responded to in a timely manner, the rest of the attack chain can be obviated.

Closing Thoughts

Not everyone has the ability to ingest STIX/TAXII, or Sigma rules, or other means of automated tooling, and as such, greater value can be derived from open reporting if observables are shared. This way, analysts from across the cyber spectrum...DFIR, detections, threat hunting, etc...can look at the data, see what things "look like" on systems and within their infrastructure, and then determine how best to apply them within the realm of their capabilities. As a DFIR analyst, I look for what I can use to create artifact constellations to increase the fidelity of detections, either for live monitoring/response within an enterprise, or during a more traditional "dead box" or "triage" DFIR process.

Additional Item of Note

Apparently, on more recent server versions of Windows, when process tracking is enabled, hashes are recorded in the AppLocker Event Log.

Timestomping Registry Keys

If you're worked in DFIR or threat intel for any amount of time, you've likely either seen or heard how threat actors modify systems to meet their own needs, configuring systems to provide data or hide their activities, as they make their way through an infrastructure. From disabling services, to modifying the system to maintain credentials in memory in plain text, to clearing Windows Event Logs, sometimes it seems that the threat actor knows more about the platform than the administrators. These system modifications are used to either provide easier access to the threat actor, or hide the impacts of their activities by "blinding" the administrators, or simply be removing clear evidence of the activity. Sometimes these system modifications go beyond the administrators, and meant to instead hamper/impede the efforts of forensic analysts investigating an incident. Today, thanks to the efforts of a bright, shining star in DFIR, we'll take a look at one such possible technique, one that hasn't been addressed in some time.

Continuing with her excellent content creation and sharing, Lina recently illustrated another means threat actors can use to disguise their activity on systems and hide their presence from DFIR analysts and threat hunters; in this case, Lina shared awareness of a technique to modify the LastWrite times on Registry keys. As we've seen in the past, Lina's blog posts are comprehensive, well-thought-out, and extremely cogent.

In her blog post, Lina used Joakim Schicht's SetRegTime (wiki) to modify Registry key LastWrite times, providing several attack demonstrations. She then followed it up with detection methodology insights, providing additional thoughts as to how threat hunters and DFIR analysts might go about determining if this technique was used. I was particularly interested in her "part 2", relying on key LastWrite time discrepancies in hopes of spotting the use of such a technique.

In addition to her blog post, Lina also tweets out her content, and in this case, Maxim stepped up to provide some additional color to Lina's content, providing more detection techniques. Maxim specifically mentioned the use of Registry transaction logs, something he's addressed in detail before in his own blog.

Other resources regarding Registry transaction logs and tools can be found:
- Andrea Fortuna (uses regipy)
- WindowsIR (refs Maxim's yarp + registryFlush.py)
- Mandiant

More Detection Possibilities
Adding to both Lina and Maxim's incredible contributions regarding detections, other possible detection methodologies might include:

** The use of the RegIdleBackup Scheduled Task; you might remember that this task used to backup the system Registry hive files into the C:\Windows\system32\config\RegBack folder. I say "used to" because a bit ago, we stopped seeing those Registry hive backups in the RegBack folder. Per Microsoft, this change is by design, but there is a way to get those hive backups back, by setting the EnablePeriodicBackup value to "1" and rebooting the system. 

** Or, you can create your own Scheduled Task that uses reg.exe to create periodic hive backups, with names appended with time stamps in order to differentiate individual backups.

Both of these methodologies would serve purposes beyond simply detecting or verifying the use of Registry key time stomping techniques. However, both of these methodologies require that system owners modify systems ahead of an incident, and I'll admit that the reality is that this simply doesn't happen nearly enough. So, what can we do with what we have?

Lina had a great detection methodology in "part 2", in that looking at an arbitrary key with subkeys, the line of reasoning is that the key LastWrite time should be equal to or more recent than the subkeys; remember that adding, deleting or modifying a value beneath the key via the usual API will cause the key LastWrite time to be updated, as well. This is an interesting approach, and would apply only under specific circumstances, but it is definitely worth testing. 

Some additional thoughts...

If an adversary copies the SetRegTime executable over to a system and uses it in a similar manner to the way Lina described, there may be indications of the use available via EDR telemetry, as well as the ShimCache and AmCache.hve files. If there's an entry in the AmCache.hve file, then the entry may also include a hash (even given the limitations of that process). This approach (by the adversary) isn't entirely underheard of, either copying the executable file over to the system, downloading once they're on the system, or including the executable in the resource section of another executable. Of course, if the adversary includes the code from the SetRegTime executable into their own, then that's a whole other ball of wax, but the key thing to remember is that nothing bad happens on a system without something happening, and that something will leave traces or an indicator.

There are a number of examples of the use of SetRegTime on the wiki; if some of the example time stamps are used, there's potential for a possible detection mechanism (yes, the wording there was intentional). Registry key LastWrite times are 64-bit FILETIME objects, or "QWORDs", which are comprised of two "DWORDs". Examples used in the wiki, such as "1743:04:01:00:00:00:000:0000" will result in one of the DWORDs consisting of all zeros. As it is unlikely the case that such a loss of granularity would be unintentional, so reading the two DWORDs and checking to see if one is all zeros might be a good automated DFIR analysis technique, either across the entire hive or by focusing on a subset of keys.

Conclusion
So, again...fantastic content by both Lina and Maxim! Be sure to visit both of their blogs, as well as give them a follow on Twitter for more amazing content!

Lina - blog - Twitter
Maxim - blog - Twitter

Addendum: After publishing this post, I wrote a RegRipper plugin (based on the sizes.pl plugin) to run through a hive file and find all the keys that had LastWrite times that were smaller/older than their most recently-updated subkey...and it turns out, there are a LOT! It seems that doing something...anything...that updates a subkey and causes the LastWrite time to be updated does not then roll that change up to the subkey's parent. This would be necessary for this detection methodology to work.

Scheduled Tasks and Batteries

Krzysztof shared another blog post recently, this one that addresses the battery use and the battery level of a system, and how it applies to an investigation.

At first thought, I'm sure a lot of you are asking, "wait...what?", but think about it for a moment. Given the pandemic, a lot of folks are working remote...a LOT. There are a number of firms that are international, with offices in a lot of different countries all over the world, and a great many of those folks are working remotely. Yes, we've always had remote workers and folks working outside of office environments, but the past 2+ years have seen something of a forced explosion in remote workers.

Those remote workers are using laptops.

And it's likely that they're not always connected to a power supply; that is, there will be times when the systems are running on batteries. As such, Krz's blog post is a significant leap forward in the validation of program execution. After all, Krz points out one particular artifact in his blog post, describing it as "one of the few artifact providing process termination." (emphasis added)

So, why does this matter? Well, a couple of years ago (okay, more than "a couple") I was working a PCI forensic examination for an organization ("merchant") that had been hit with credit card theft. In examining the back office server (where all of the credit card purchases were processed), we found that there was indeed credit card theft malware on the system. We found the original installation date, which was a key component of the examination; this is because one of the dashboard items we had to complete on the report (Visa, then the place holder for the as-yet-unformed PCI Council, had very structured requirements for reports) was the "window of compromise"...how long was it from the original infection until the theft of data was halted. So, again, we saw the original installation date of the malware in late November of that year, but two days later, we could see that an "on demand" AV scan detected and quarantined the malware. Then, a bit more than 6 weeks later, the malware was again placed on the system, and this time we tracked repeated AV scans that did not detect this new malware.

We made absolutely sure to clearly note this in the "window of compromise". Why? Because most merchants have a pretty good idea of the numbers of credit cards processed throughout the year, particularly during different seasons (spring break, other holidays, etc.). We were able to clearly demonstrate that during the Thanksgiving and Christmas holiday seasons, the malware was, in fact, not installed and running on the system. This means that during "Black Friday", as well as the run-up to Christmas, the malware was not stealing credit card numbers from this merchant. We needed to make absolutely sure that this was understood, so that when any action was taken or fines were levied against the merchant, this fact was taken into account.

This is just one example of why we need to validate program execution. Krz's blog post clearly demonstrates yet another. Over the past 2+ years, there's been an explosion of remote work, one that has persisted. Employee systems clearly serve as an entry point into organizations, and as Krz pointed out, many threat actors opt to use Scheduled Tasks as their persistence mechanism.

As Krz pointed out, the Task Scheduler UI has options for setting these conditions; however, the LOLBin schtasks.exe does not provide command line options for enabling or disabling the condition. So, by default, when schtasks.exe is used to create a scheduled task, these conditions are going to be set as Krz shared, by default.

As Krz pointed out, there are some ways to change this; for example, if the threat actor has access via the UI (logged in via RDP, or any other remote desktop capability) they can open the Task Scheduler and make the change. Another way is to use the schtasks.exe command line option to create the scheduled task from an XML file. Or, perhaps you can use Powershell, if it gives you greater control of the conditions of the scheduled task.

From a threat hunting perspective, look for either the use of schtasks.exe with the "/xml" command line option, or for alternate means of creating scheduled tasks that allow for modification of the conditions. For example, Powershell's Set-ScheduledJobOption module includes options such as "-RequireNetwork" and "-StartIfOnBattery".

From a DFIR perspective, analysts can either scan all scheduled task XML files for those set to not stop running when the system goes to batteries, or simply open the XML file for the suspicious task and view it manually. Anytime analysts see the Task Scheduler UI being opened (observed during DFIR analysis), they might want to consider taking a closer look at any changes to tasks that may have occurred.

Something else to consider during DFIR analysis, particularly when it comes to malware persisting as a schedule task, is the idle state of the system. I'll just leave that right there, because it applies directly to what Krz described in his blog post, and impacts the validation of program execution in a very similar manner.

Windows Event Log Evasion Review

Before I kick this blog post off, I'd like to thank Lina L for her excellent work in developing and sharing her work, both on Twitter, as well as in a blog post. Both are thoughtful, cogent, and articulate.

In her blog post, Lina references detection techniques, something that is extremely important for all analysts to understand. What Lina is alluding to is the need for analysts to truly understand their tools, and how they work.

Back around 2007-ish, the team I was on had several members (myself included) certified to work PCI forensic investigations. Our primary tool at the time for scanning acquired images and data for credit card numbers (CCNs) was EnCase (at the time, a Guidance Software product)...I believe version 6.19 or thereabouts. We had a case where JCB and Discover cards were included, but the tool was not finding the CCNs. Troubleshooting and extensive testing revealed that the built-in function, isValidCreditCard(), did not apply to those CCNs. As such, we worked with a trusted resource to write the necessary regexes, and override the function call. While this was slower than using the built-in function, accuracy took precedence over speed.

The point is, as analysts, we need to understand how our tools work, what they do, and what they can and cannot do. This also applies to the data sources we rely on, as well. As such, what I'm going to do in this blog post is expand on some of the items Lina shared in part 3 of her blog post, "Detection Methodology". She did a fantastic job of providing what amounts to elements of an artifact constellation when it comes to the evasion technique that she describes.

Let's take a look at some of the detection methodologies Lina describes:

1. Review event logs for 7045, 7035, 7034, 7036, 7040, 4697 service creation

Most of these event IDs appear in the System Event Log, with a source of "Service Control Manager" (event ID 4697 is found in the Security Event Log) and they all can provide indications of and useful information about a service.

2. Review registry keys for services:

Given the content of Lina's post, this is an excellent source of data. In the face of anti-forensic techniques, also consider extracting deleted keys and values from unallocated space within the hive file, as well. Also, look for unusual LastWrite times for the parent keys, particularly if you're performing a live "triage" response and collecting Registry hives from live systems.

3. Review command line logging for signs of services being created using “sc.exe”, “at.exe”

I'm not sure about how "at.exe" would be used to create a service (maybe we can get Lina to share a bit more about that particular item...), but definitely look for the use of "sc.exe" if you have some sort of command line logging. This can take the form of enabling Process Tracking (along with the associated Registry modification to add the full command line) in the Security Event Log, installing Sysmon, or employing an EDR capability.

4. Review artefacts for execution i.e. Shimcache, Prefetch, Amcache

Prefetch files are a great artifact if you're looking for artifacts of execution, but there are a couple of things analysts need to keep in mind. 

First, Prefetch files can contain up to 8 time stamps that refer to when the target file was executed; as such, be sure to extract them all. 

Second, application prefetching is controlled via a Registry value, and while that value is enabled by default on workstation versions of Windows, it is not enabled by default on the server versions. Accordingly, this means that it can be disabled on workstations; as such, if you're NOT seeing a Prefetch file when you would expect to, check the value and the LastWrite time of the key. I highly recommend this as a means of validation, because without it, saying, "...the file was not executed..." is just guessing. Think about it...why delete a file or artifact, when you can simply tell Windows to not generate it?

Third, Dr Ali Hadi has done some great work documenting the effect of launching files from ADSs on Prefetch file creation and location. I'm not sure how many folks are aware of this, but it's something to keep in mind, particularly if a threat actor or group has previously demonstrated a proclivity for such things.

Finally, it's easy to say that ShimCache and AmCache entries constitute "artifacts of execution", but that's not completely accurate. While both data sources do constitute indicators of execution, they're just that...indicators...and should not be considered in isolation. While they may be incorporated into artifact constellations that demonstrate program execution, by themselves they do not definitively demonstrate execution.

So, if we create an artifact constellation, incorporating ShimCache, AmCache, Prefetch, command line logging, etc., and all of the constituent elements include time stamps that align, then yes, we do have "artifacts of execution". 

7. Detect the malicious driver on the disk (can also be done without memory forensics by correlating creation timestamps on disk)

This is a good detection technique, but we need to keep things like file system tunneling and time stomping in mind. I've seen cases where the adversary time stomped their malware, and when it was 'recorded' in the ShimCache data, the analyst (mis)interpreted the time stamp as the time of execution. This meant that during a PCI forensic investigation, the "window of compromise" reported to the PCI Council was 4 yrs, rather than the true value of 3 wks. For anyone who's been involved in such an investigation, you very likely fully understand the significance of this "finding" being reported to the Council.

Some Additional Thoughts, Re: Windows Event Log Evasion
Locard's Exchange Principle tells us that when two objects come into contact with each other, material is exchanged between them. We can apply this equally well to the digital realm, and what this ultimately boils down to is that for something bad to happen on a system, something has to happen.

As a result, when it comes to Windows Event Log "evasion", we would want to look for other changes to the system. For example, if I want to hide specific event records within the Security Event Log, there are three approaches I might take. One is to use the LOLBin auditpol.exe to enable ALLTHETHINGS!, and overwhelm the Security Event Log, and subsequently, the analyst. I've been one engagements before where so much was being audited in the Security Event Log that while we had data going back weeks or months in the other logs, the Security Event Logs covered maybe 4 hours. I've also seen much less, about half of that. The overall point here is that the Windows Event Logs are essentially circular buffers, where older event records aren't "pushed off the stack" and into unallocated space...they're overwritten. As such, "older" records aren't something you're going to be able to recover from unallocated space, as you would in the case of cleared Windows Event Logs. As a result, things like type 10 login events (event ID 4624 events) can get overwritten quickly, and will not be recoverable.

Clearing Windows Event Logs is easy (via wevtutil.exe), but it is also easy to detect, based on artifact constellations such as a Prefetch file for the LOLBin, event IDs 1104 and 102, etc. And, as we saw with a great deal of the work done following the NotPetya attacks in 2017, cleared event records are pretty trivial to recover from unallocated space. I say, "trivial", but I completely understand that for some, something like this would not be trivial at all. While we do have a process available to help us recover the data we need, it isn't easy for some. However, clearing Windows Event Logs is tantamount to a streaker running across the field at the Super Bowl or the World Cup...it's a way of letting everyone know that something bad is going on.

The other option might be to simply disable logging all together. You can do this via the Registry, without disabling the Event Log service, and the great thing is that if there's nothing deleted, there's nothing to recover. ;-)  

The third option is a bit more involved, and as such, potentially prone to discovery, but it is pretty interesting. Let's say you're accessing the system via RDP, and you have admin-level access. You can use different techniques to escalate your privileges to System level, but you have to also be aware that when you do, your activities will populate artifacts in a different manner (but this can be a good thing!!). So, start by using wevtutil.exe to backup all but the last 4 min of the Security Event Log, using a command such as:

wevtutil epl Security Security_export.evtx /q:"*[System[TimeCreated[timediff(@SystemTime) >= 14400000]]]" /ow:True

Now, this is where the elevate privileges come in...you need stop the EventLog service (via 'net stop'), but you first have to stop its dependent services. Once everything is stopped, type:

copy /Y Security_export.evtx C:\Windows\system32\winevt\Logs\Security.evtx

Now, restart all the services, in reverse order that you stopped them, and delete the Security_export.evtx file. You've now got a Security Event Log that is missing the last 4 min worth of event records, and the "interesting" thing is that when I tested this, and then dumped the Security Event Log, there was no gap in record sequence numbers. The log apparently picks right up with the next sequence number.

But again, keep in mind that this activity, just like the other options presented, is going to leave traces. For example, if you use PSExec to elevate your privileges to System, you're going to need to accept the EULA the first time you run it. You can use something else, sure...but there's going to be a Prefetch file created, unless you disable prefetching. If you disable Prefetching, this causes a Registry modification, modifying the key LastWrite time. And if you disable Prefetching, what about the "command line logging" Lina mentioned?

Ultimately, the choice of option you decided upon, even if it's one that's not mentioned in either Lina's blog post or this one, is going to depend upon you weighing your options regarding the artifacts and traces you leave.

The (Mis)Use of Artifact Categories, pt II

My previous post on this topic presented my thoughts on how the concept of "artifact categories" were being misused.

My engagement with artifact categories goes back to 2013, when Corey Harrell implemented his thoughts on categories via auto_rip. I saw, and continue to see, the value in identifying artifact categories, but as I alluded to in my previous post, it really seems that the categories are being misused. Where the artifacts should be viewed as providing an indication of the categories and requiring further analysis (including, but not limited to the population of artifact constellations), instead, the artifacts are often misinterpreted as being emphatic statements of the event or condition occurring. For example, while an entry in the ShimCache or AmCache.hve file should indicate that the file existed on the system at one point and may have been executed, too often either one is simply interpreted as "program execution", and the analyst moves on with no other validation. Without validation, these "findings" lead to incorrect statements or understanding of the incident itself.

Program Execution
There was discussion of the "program execution" category in my previous post, along with discussion of the need to validate that the program did, indeed, execute. Often we'll see some indication of a program or process being launched (via EDR telemetry, an entry in the Windows Event Log, etc.) and assume that it completed successfully.

Keeping that in mind, there are some less-than-obvious artifacts we can look to regarding indications of "program execution"; for example, consider the Microsoft-Windows-Shell-Core\Operational.evtx Event Log file.

Some notable event IDs of interest (all with event source "Shell-Core"):

Event ID 9705/9706 - start/finish processing of Run/RunOnce keys

Event ID 9707/9708 - indicates start and stop of process execution, with corresponding PID.

Event ID 62408/62409 - start/finish processing of <process>

Some additional, useful information - from Geoff Chappell's site, we can see that the event ID 9707 records pertain to the "ShellTraceId_Explorer_ExecutingFromRunKey_Info" symbol.

While the events are restricted to what's processed via the Run and RunOnce keys, we may see the records provide us with full process command lines. For example, and entry for an audio processor included "WavesSvc64.exe -Jack", which appears to be the full command line for the process. This is a bit better information than we tend to see when Process Tracking is enabled in the Security Event Log, leading to event ID 4688 (Process Creation) records being generated; many organizations will enable this setting, but then not also enable the corresponding Registry modification that allows the full command line to be added to the record.

"Program Execution" is not the only category we should look to go beyond the basic indicators that different resources provide analysts; for example, devices connected to a Windows system, particularly via USB connections, are another category that would benefit from some clarification and exploration.

USB Devices
Cory Altheide and I published a paper on tracking USB devices across Windows systems in 2005; at the time, Windows XP was the dominant platform. Obviously, that field has changed pretty dramatically in the ensuing 17 years. In 2015, Jason Shaver's NPS master's thesis on the same topic was published, giving us an updated view of the topic. As you'd expect, Jason's thesis is a pretty thorough treatment of the topic, but for anyone who's been involved in DFIR analysis of Windows systems is likely aware that there have been a number of build updates to Windows 10 that, over time, have changed how the operating system responds to or records various activities.

In addition, Nicole Ibrahim has done considerable work regarding different types of USB devices and their impact on Windows systems, based on the protocols used. The take-away from Nicole's research is that not all devices are treated the same, just because they're connected via a USB cable. Different devices (i.e., USB thumb drives, smartphones, etc.), while presented via a common interface, often use different underlying protocols, and therefore require different examination routes.

A note on connecting USB devices to Windows systems...Kevin Ripa recently published an article on that topic where he points out that how you connect the device can make a difference. The key here is to be very aware of the process Kevin went through, as well as his assumptions...both of which he was very clear about. For example, the first device he connected wasn't a USB thumb drive; rather, it was a hard drive connected via a USB cable. Then, he connected the same hard drive via a T-300D Super Speed Toaster, and stated, Now I don’t know about you, but I would have expected a device such as this to simply be a pass-through device. I'd have to say, given that the device is described as a stand-alone disk duplicator, I would not have assumed that it would "simply be a pass-through device" at all. As such, I don't agree that the tools are telling lies, but I do agree that if you're connecting a device to a Windows 10 system, you need to be clear about the device, as well as how it's connected.

Back to Nicole's research, the take-away is that not all "USB" devices are the same. For example, a USB thumb drive is not the same as a smartphone, even though both are connected via a USB cable. For USB thumb drives and external hard drives, I've found a good bit of evidence in the Microsoft-Windows-StorageSpaces-Driver\Operational.evtx Event Log, specifically in event ID 207, which contains drive model and serial number information.

For my iPhone, the Microsoft-Windows-WPD-MTPClassDriver\Operational.evtx Event Log contains event ID 1005 records contain messages such as "Customizing for <device>", which points to the smartphone. I've connected my iPhone to my computer upon occasion, to copy pictures over or to use iTunes to update my music playlists on the device. These event ID 1005 records correspond to when I've connected that phone to the system, and will likely show other iPhones I've connected, as well - I don't do this too often, so the log should not be too terribly populated.

For other useful Windows Event Logs that can provide additional information that may be of use to your investigation, consider checking out Nasreddinne or Adam's pages, both of which allude to "obscure" or less-commonly-referred-to event logs.

Take-Away
What we have to remember from all this is that the artifact categories provide an indication of that category, a sign post that tells the analyst that further examination is necessary. As such, the indicator is the beginning of the examination, not the end. Because a file name appeared in the ShimCache or AmCache, we should not simply jump ahead and assume that the file was executed; rather, we should look for other indications of program execution (Prefetch file, impact of the file execution on the system, etc.), other artifacts in the constellation, before establishing the finding that the program was, in fact, executed.

DFIR Reporting

A request that's been pretty consistent within the industry over time has had to do with reporting. I'd see a request, some responses, someone might ask for a template, and then the exchange would die off...I assumed that it had moved to DMs or offline. Then you'd see the discussion pop up again later, in some other forum.

I get it...writing is hard. I have the benefit of having had to write throughout my career, but also of putting intentional, dedicated effort into DFIR reporting, in that I had been very purposeful in seeking feedback from my boss, and incorporating that feedback into report writing. I was able to get to the point of having reports approved with minimal (if any) changes pretty quickly. 

As a result, in 2014, Windows Forensic Analysis Toolkit 4/e was published, and in this edition, I included a chapter on reporting. It was (and still is) a general overview addressing a lot of things that folks miss when it comes to technical reporting, going from the importance of spelling and grammar to the nature of an "Executive Summary" and beyond.

About a year ago, Josh Brunty wrote a blog post on Writing DFIR Reports; 7 yrs later, and his blog post included some of the same thoughts and recommendations I'd shared in my book. It was validating to see that others had had (and shared) similar thoughts regarding reporting. Different words, different experiences, different person, but similar thoughts and direction. Cool.

So why does any of this matter? Not to put too fine a point on it, but it doesn't matter how good or thorough you are, it doesn't matter if you're technically light years beyond the bad guys. If you can't communicate your findings to those to whom it matters, in an actionable manner...who cares? What does any of it matter?

Coworkers and others in the community have long chided me for my insistence on correct spelling and use of terminology (i.e., specificity of language), in some instances saying, "yeah, well you know what I meant...". Okay, but a report or Jira ticket regarding an incident is not intended to be a placeholder for "what you meant", because 6 months or a year from now, you may not remember what you meant. Or, as is more often the case, someone other than you who's looking at the report will get the wrong information, because they're bringing a whole new set of understanding to "what you meant". As to spelling, let's say you absent-mindedly drop the last digit from the last octet of an IP address...rather than ".245", it's ".24". If you were to search for that IP address across other data sources, you'd still find it, even with the final digit missing. But what happens when you drop that IP address into a block list? Or, what happens if (and I ask because this has happened) the digit is mistakenly dropped from the second octet? All of it fails...searches, blocks, etc. At the very least misspelling words simply makes the report or ticket appear unprofessional, particularly given the number of tools out there with built-in spell check. However, misspelling can also lead to material impacts to the information itself, altering the course of the investigation. Misspelling a system name or IP address can be the difference between an AD server and a user's workstation. Misspelling an IP address or domain means that it's not actually blocked, and traffic continues to flow to and from that remote system, unabated. The issue is that when the report or ticket is the means of communication, intention and "you know what I meant" is impossible to convey.

When I got started in the private sector information security business back around 1997-1998, I was working with a team that was performing vulnerability assessments. We had a developer on our team who'd developed an Access database of report excerpts based on various findings; we could go into the interface and select the necessary sections (based on our findings) and auto-populate the initial report. We had a couple of instances where someone either wrote up a really good finding, or re-wrote a finding that we already had a truly exceptional manner, and those entries were updated in the database so that someone could take advantage of them. Our team was small, and everyone was on-board with the understanding that generating the initial report was not the end of our reporting effort.

However, we had one forensic analyst as part of our "team"...they didn't go on vulnerability assessments with us, they did their "own thing". But when their work was done, it usually took two analysts from the assessment team to unravel the forensic findings and produce a readable report for the customer. This meant that resources were pulled from paying work in order to ensure that the contract for the forensic work made some money and didn't go into the red.

In a world where remote work, and work-from-home (WFH) is becoming much more the norm, being able to clearly, concisely, and accurately communicate is even more important. As such, if you're writing something that someone else is going to pick up later that day or week, and use as the next step for their work, then you want to make sure that you communicate what needs to be communicated in a manner that they can understand and use. 

At the very least, you want to communicate in such a manner that you can come back a year later and understand what you'd meant. I say this, and like with most things in "cyber", we all look at this as a hypothetical, something that may happen, but it's not likely. Until it does. I worked with one team where we said that regularly - someone would continually ask, "what's the standard?" for writing, and we'd say, "...so that you can come back to it a year later and understand what was going on, and correctly explain what happened." This was what our boss, a former cop, had said. And no one listened, until an analyst we'll call "Dave" had to review a report that had been written 12 months prior. He couldn't make heads or tails of the report...what exactly had been examined, what was the original analyst looking for, and what did they find? All of this was a mystery, not just to "Dave" but to other analysts who reviewed the report. The reports were all written from the company, to the customer, but we tracked down the analyst through contracting...it was Dave. The customer was raising a legal complaint against our company, and we had no way of figuring out if they had a legitimate complaint or not because no one, not even Dave, could figure out what had been delivered.

The (Mis)Use of Artifact Categories

Very often in DFIR, we categorize artifacts in an easy-to-understand and easy-to-digest manner, as using or relying on these categories often helps us navigate our investigations. There are also times when we reduce those artifacts to a level where they're easier to understand, and in doing so, the categorization of the artifact isn't quite accurate. As such, it's necessary now and again to go back and take a look at that categorization to determine if still holds, or if it truly served the community in the manner intended.

SPOILER ALERT - TL:DR 
Within the DFIR community, we should not be hanging investigation findings on single artifacts in isolation. If there are gaps in data, they need to be recognized, understood and communicated. Do not spackle those gaps over with guesswork and assumption; instead, ensure that you're validating your findings through artifact constellations.

Program Execution
One such artifact category is Program Execution. As with other categories, this one often lists single artifacts, in isolation, that provide an indication to the examiner that a program may have been executed on the endpoint. This issue of the category's misuse sprouts from when analysts do not use it as an indication for further investigation, but instead look to those single artifacts on which to build their findings, without further validation or support.

To start, the MITRE ATT&CK framework includes an "Execution" tactic, and the description of the Execution tactic includes the following:

The adversary is trying to run malicious code.

Execution consists of techniques that result in adversary-controlled code running on a local or remote system. Techniques that run malicious code are often paired with techniques from all other tactics to achieve broader goals, like exploring a network or stealing data.

Note that the description specifies "...trying to run code"; this does not say that it succeeded. This is an apt and necessary distinction, as there are times (many, many times) when code is attempted to be run but is not successful for some reason. As stated in the description, the tactic provides a number of techniques that describe how an actor might attempt to initiate execution of a program or process, but that does not guarantee that the code runs successfully.

The SANS DFIR poster includes a "Program Execution" section, which includes individual artifacts such as ShimCache, AmCache, etc. all of which are meant to provide indications of...yes..."program execution". However, some of the artifacts mentioned do not specifically indicate that a program executed (only that the file existed on the system) in and of themselves, while others provide simply an indication that an actor (the user or a threat actor) may have attempted to initiate a program. The important thing to remember here is that these indicators are just that...indicators...and that further analysis is required.

As it turns out, we (those of us in the DFIR community) are misusing the term "program execution", to the point where a more apt description might be that we're abusing it. What I mean is that we may look to a single artifact...EDR telemetry, a ShimCache entry, UserAssist entry, or another Registry entry of some kind...and assume that it means that a program was executed, that it was launched or started, and at some point it successfully completed execution. As such, the "program execution" category can sometimes be specious; attempts may have been made to create a process, but for some reason, those attempts failed. As such, there was no actual "program execution", in the sense that a process was created and completed it's intended function. Relying on a single artifact to support a finding or theory is insufficient analysis, and can get us into trouble because we will be incorrectly reporting what occurred on the system.

Instances of "program execution" misuse result from insufficient investigations, and often start out as a SOC alert based on NDR or EDR telemetry, or as an initial finding during a DFIR investigation. If we suspect that code has been executed, or we're attempting to establish if code has been executed, we need to ensure that we're not basing our findings on single "program execution" artifacts in isolation, but instead pursuing additional artifacts within the constellation to support our finding.

What we should expect to see (artifact constellation/toolmarks):
- Prefetch file, depending upon the Windows version
- UserAssist entry, if launched by the user double-clicking via Explorer
- Impact of the execution on the system (Registry keys/values, Windows Event Log records, etc.)

Sometimes we might not find these additional artifacts from the constellation; if this is the case, we need to determine why. 

What can impact "program execution":
- AV, NGAV, EDR (in block mode)
- Privilege management software (BeyondTrust, OneIdentity, etc.)
- System configurations
- Coding errors
- System region or "locale" settings

The point is that in some cases, we may "see" what we think is an attempt to launch a program or script, but we need to look beyond that single artifact, and examine the system more broadly to validate the finding. Did Windows Error Reporting (WER) kick off as the launch attempt occurred? Was an application popup error message or a crash dump generated? Was a log entry generated as a result of UAC or some other protection mechanism blocking the execution?

We need to ensure that when we see a single artifact in isolation, we have to ensure that we're validating our findings through the use of artifact constellations and toolmarks.

A Closer Look At Some Artifacts
What do some of the artifacts that we look to as indicators of "program execution" really tell us? What do they really mean?

With respect to the ShimCache artifacts, there is a Mandiant blog post from 2015 which states (emphasis added):

It is important to understand there may be entries in the Shimcache that were not actually executed.

Further, in this article from CountUpon Security, we see (emphasis added):

In addition the ShimCache tracks executables that have not been executed but were browsed for example through explorer.exe. This makes a valuable source of evidence for example to track executables that were on the system but weren’t executed...

I should note that many of these articles are older, covering Windows XP and Windows 7/2008, and there have been some modifications to what is available in Windows 10. For example, the ShimCache entries on Windows 10 still maintain the time stamp and file path, but the "execution flag" seen on earlier versions of Windows does not appear to be available. However, the time stamp within the entry is still the file system last modification time, extracted from the $STANDARD_INFORMATION attribute within the MFT. As such, if the threat actor were to create the file on the system (copy it over, extract it from an archive, etc.), and then time stomp the file, when the file is added to the ShimCache, it will have the "new", albeit incorrect time data. I've seen this happen on a number of incidents, specifically with respect to PCI forensic investigations, where an accurate understanding of the "window of compromise" is mandated by the PCI Council.

As for the AmCache artifacts that may be found, this paper provides a much more detailed examination of the forensic uses of the artifact, based on library versions, and within the paper, those libraries are associated with specific Windows 10 builds. A thorough read of the paper leaves us with the clear understanding that simply because there is an entry in the AmCache for a file, this does NOT specifically indicate that it was executed. For example, section 6.2 states (emphasis added):

Secondly, the last write time of the subkey coincides with either the first time of execution of the PE or the time of installation of the program.

Given this, while the AmCache is listed as an "indicator of program execution", we cannot simply state that there was, in fact, program execution based on an entry in the file. Where the entry is located (beneath which key) within the AmCache.hve file is an important factor, as is the fact that the existence of the entry does not specifically correlate to program execution. 

Consider this tweet from Maxim Suhanov (circa Nov, 2018):

Amcache entries are created for executables that were never executed. Executables that were launched and then deleted aren't recorded. Also, Amcache entries aren't created for executables in non-standard locations (e.g., "C:\1\2\") _unless_ they were actually executed.

As such, it should be clear that, in isolation, AmCache entries do not explicitly state that a program was run, but rather provides an indication that the file was on the endpoint, and may have been run.

Something else Maxim has also pointed out is that the hashes in the AmCache file are generated for the first 30Mb of the file. As such, if the file is greater than 30Mb, the hash you generate for the file itself will not match what's listed in the AmCache.hve file, and the hash from the AmCache.hve file should not be used for open source searches.

LNK Files, Again

What, again?!?!

I know, right?!?

Not long ago, I read this fascinating article from Joe Helle that discussed malicious uses for Windows shortcuts, or LNK files, and also discussed a Python3 scripts called "lnkbomb".

As a side note, check out what Joe had to share about persistence via WSL2!

As anyone who's followed me for a minute knows, I love...L   O   V   E...me some LNK files. Shortcut files are something that we see all the time, have been around for a long time (much like ADSs), but folks in the DFIR field are so focused on the "shiny hot newness", that this file type is very often overlooked and not fully exploited.

The technique Joe discusses is similar to modifying the iconfilename field of a shortcut file, so that even if the "bad guy" is evicted from an infrastructure, any action that launches the LNK file results in credentials being passed via HTTP or WebDAV, where they can be collected, cracked, and then used by the threat actor.

LNK files have a lot of uses, and understanding the format and structure is helpful in a lot of different ways. One example is that automatic JumpLists follow the OLE/structured storage format, and all but the DestList stream consist of LNK file formatted streams. Another example is that the building blocks of LNK files, shell items, are also the core building blocks of several Registry-based artifacts, such as shellbags.

Beyond that, however, threat actors have used LNK files as lures in social engineering and phishing attacks; this means that the threat actor has built the LNK files within their own infrastructure, within their own development environment. As such, sending these files as lures is "free money" to both DFIR and CTI analysts, if they're able to leverage those files and their component metadata.

So...while I know Windows 11 is out, and everyone's excited about the shiny new hotness, let's not forget that there's a lot that has worked since Windows XP (or even prior to that) and still continues to be an issue today.

Addendum, 12 Feb: After I published this post, Dr. Ali Hadi provided me with a link (get it??) to a site that talks about embedding an EXE in an LNK, with automatic execution. I've actually seen these "in the wild" before, but it's been a while! Thanks, Ali!

The Threat Landscape and Attribution

Over the years, changes in the threat landscape have made attribution more difficult. Attribution has always been challenging, but has been and can continue to be eased through visibility. That is, if your view into an event or campaign is limited to resources such as malware samples pulled from public repositories, then attribution can be challenging. Even adding information regarding infrastructure extracted from the sample configs can still give a somewhat limited view. However, as visibility is expanded to include data from intrusions and incidents, attribution becomes clearer and more granular.

I ran across A Complex Threat Landscape Muddles Attribution recently and found it to be a fascinating, insightful read, one that anyone involved in threat intelligence, even peripherally, should take a good, thoughtful, intentional look at, marinate on it, and then contribute by sharing their own and thoughts and insights. This isn't something that you should just read over once, check the box that you read it, and move on.

I thought I'd take a few minutes to share some of my own thoughts. I'm not what anyone would refer to as a "threat intelligence professional". I don't have a military or LE intel background. However, what I am is a DFIR professional who sees, has seen, and has demonstrated the value of leveraging threat intel to further DFIR activities. I've also seen and demonstrated the value in leveraging DFIR activities (those that go beyond keyword and IOC searches) to further the threat intel picture, and subsequently, attribution. To that end, I spoke several times during 2021 on the topic of using DF analysis (specifically, analysis of the Windows Registry) findings to further the understanding of actor intent, "sophistication", and ultimately, attribution. One of the instances that I spoke on the topic was a half-day training event for federal LE.

I should note that Joshua M. (of Proofpoint) is one of the folks quoted several times in the article. I mention this largely to illustrate his background (check out his LinkedIn profile) as a counterpoint to my own. Joshua is what one would likely refer to as a more traditional intelligence professional.

I hope that brief description level-set the lens through which I'm viewing the content of the article. I get that we all have different perspectives, due in large part to each of us bringing our own experiences and knowledge to bear when reading and thinking about such things.

The first sentence of the article really sets the tone:

The sheer fluidity of the threat landscape is making the challenging process of attribution even more difficult for researchers.

IMHO, it's a good idea to unpack this a bit, not so much for the threat intel folks who've been doing this work for 20 yrs, but for everyone else. What this means is that "back in the day", there were some pretty clear delineations between activities. For example, "APT" (a.k.a., "nation-state" or "targeted") threat actors were distinctly different from 'e-crime' actors; different in how attacks and campaigns were organized and executed. Of course, if you look at the definitions used at the time, the Venn diagram included an overlap between "APT" and "e-crime" threat actors, in the form of credit card theft (PCI) attacks; these were considered 'e-crime' but were also clearly 'targeted'. However, the involvement of regulatory bodies (Visa, then later the PCI Council) served to move these attacks into an outlier status, the "everything else" column.

Over the years, we started to 'see' that the sharp lines of delineation between activities of 'nation-state' and 'e-crime' threat actors were becoming blurred; at least, this is what was being stated at presentations and in open reporting. I'll admit, I was seeing it as well, but I was seeing it through a different lens; that is, while a lot of threat intel is based on analysis of malware samples, the team(s) I worked with were quite literally following the threat actors, through a combination of active monitoring (EDR telemetry) and DF analysis. The EDR technology we were using was capable of not only monitoring from the point of installation going forward, but also of taking a "historical" look at the system by extracting, parsing, and classifying data sources on the system, that were populated prior to the installation of the EDR monitoring function. This provided us not only with unparalleled visibility into systems, but also allowed us to quickly scope the incident, and also quickly identify systems that required a closer look, a deeper DFIR examination. For example, on one engagement, there were over 150,000 total endpoints; we found that the threat actor had only "been on" a total of 8 systems, and from there, only needed to do a deep forensic analysis of 4 of those systems.

Finally, the reference to "researchers" can be viewed as a way of separating those attempting to perform attribution. A "researcher" can be seen as different from a "practitioner" or "responder", in that a researcher may be interacting with a somewhat limited data source (i.e., malware samples downloaded from a public repository) where a "practitioner" or "responder" might be engaging with a much wider range of data, including (but not limited to) EDR telemetry, logs, endpoint data acquired for analysis, etc.

The second paragraph references a couple of things we've seen develop specifically with respect to ransomware over the past 2+ yrs. Beginning in Nov 2019, we started to see ransomware threat actors move to a "double extortion" model, where they announce that they've stolen sensitive data from the compromised environment, and then prove it by posting samples of the data on the web. Prior to that, most DFIR consulting firms published reports with statements akin to "...no evidence of data exfiltration was found...", without specifying what evidence was looked for, or examined. The point is, Nov 2019 was a point where we started to see real, significant changes in the "ransomware economy", specifically with respect to how the activities were being monetized. In the months since then, we've seen references to "triple extortion" (i.e., files encrypted, data stolen, and a threat to inform customers), and even more than a few references to "n-tuple extortion" (don't ask). There's even been references to some actor groups further monetizing their attacks through the stock market, shorting stocks of companies that they were planning to or had "hit". Depending upon how the attacks themselves are carried out, endpoints might include clear indications of the threat actor's activity, as well as their intent. Some systems will clearly contain data pertaining to the threat actor's initial access vector, and other systems will likely contain data pertaining to not just the tools that were used, but also how those tools were used (i.e., threat actors may not use all capabilities provided by a tool in their kit).

Also mentioned in the second paragraph, some ransomware groups have moved away from conducting attacks and deploying ransomware themselves, and shifted to a "ransomware-as-a-service" (RaaS) model where they provide the ransomware and infrastructure for a fee. Add to that access brokers who are selling access to compromised infrastructures, and the end result is that not only has there been an increase in monetization associated with such attacks, but there has also been a significant lowering of the barrier for entry into the "ransomware game".

For example, in May, 2021, Mandiant published a blog article regarding DarkSide RaaS, and specifically regarding how they'd identified five clusters of threat activity, providing details of three of these clusters or groups. Even a cursory overview of what is shared regarding these clusters illustrates how analysts need to go beyond things like malware samples and infrastructure to more accurately and completely perform attribution.

Anti-Forensics and "False Flags"
Over the years, we've seen threat actors take actions referred to as "anti-forensics", which are efforts to remove or inhibit analysis and understanding of their techniques and actions. To some extent, this has worked. However, in some instances, what it has taken to achieve those goals has left much more indelible toolmarks that can be applied directly to attribution than the data that was "removed". 

There's also "false flags", intended to throw off and mislead the analyst. These can and have worked, but largely against analysts who are trying to move too quickly, or do not have sufficient visibility and are not aware of that fact.

From the article:

“Many attacker groups have been observed to fake one or more evidence types, like planting a string of a foreign language in their malware,” he said. “But there are no documented cases of attacker groups that took the effort to plant false flags consistently in all aspects of their attacks and in all evidence types.”

While there's no elaboration on what constitutes "all evidence types", so its unclear as to what was examined; that is, malware samples were analyzed, comparing not just code but also embedded strings.

Something else to consider when researching malware samples is validation. Very often, "embedded strings" might consist of sequences of commands or batch files. For example, in the spring of 2020, one observed ransomware sample included 156 embedded commands for disabling services. Either way, the question becomes, do the commands actually work? 

Finally, the second paragraph ends with, "...analysis of the breadcrumbs left behind by threat actors - including those in the malware’s code and the infrastructure - that researchers look at during attack attribution."

I've long been of the opinion that, however unknowingly, threat actors often seem to target analysts as much as infrastructures; perhaps a more appropriate description would be that threat actors target analyst's visibility, or their access to those "breadcrumbs". After all, it's very often the breadcrumbs that provide us that attribution.

As demonstrated via the Mandiant article, what's really missing from threat intel's ability to perform attribution is visibility. For example, from a great deal of public reporting, it's less that a threat actor "disabled Windows Defender" (or other security mechanisms) and more about how they did so, because the how and the timing can be leveraged to enable more granular attribution. While some threat actor activities appear to be consistent across monitored groups, at a high level, digging into the mechanics and timing of those activities can often reveal significant differences between the groups, or between individuals within a group.

How Do You Know What "Bad" Looks Like?

From the time I started in DFIR, one question was always on the forefront of incident responder's minds...how do you know what "bad" looks like? When I was heading on-site during those early engagements, that question was foremost on my mind, and very often, the reason I couldn't sleep on the plane, even on the long, cross country flights. As I gained experience, I started to have a sense of what "bad" might or could look like, and that question started coming from the folks around me (IT staff, etc.) while I was on-site.

How do you know what "bad" looks like?

The most obvious answer to the question is, clearly, "anything that's not "good"...". However, that doesn't really answer the question, does it? Back in the late '90s, I did a vulnerability assessment for an organization, and at one of the offices I visited there were almost two dozen systems with the AutoAdminLogon value in the Registry. This was anomalous to the organization as a whole, an outlier within the enterprise, even though only a single system had the value set to "1" (all others were "0"). The commercial scanning product we were using simply reported any system that had the value by name as "bad", regardless of what it was set to. However, for that office, it was "normal" and the IT staff were fully aware of that value, and why it was there.

From this example, we can see that the universal answer applies here; "it depends". It depends upon the infrastructure in question, the IT staff engaging in and managing that infrastructure, the "threat actor" (if there is one), etc. What's "bad" in an organization depends upon the organization. 

A responder from my team went on-site and acquired the systems of one employee; the goals of the investigation were to determine if there was anything "bad" on the systems, and the responder took that request, along with the images, and headed back to the lab. They began digging into the case, and found all sorts of "hacking" tools, scripts, instructions regarding how to use some of the tools, etc., and reported on all of what they found. The customer responded that none of this was "bad"; it was expected, as the employee's job was to test the security of their external systems.

While reviewing EDR telemetry over a decade and a half later, during an incident response engagement, I saw where an Excel spreadsheet was being opened by several employees, and macros being run. I thought I might have the root cause, only to find out that, no, that was "normal", as well, and part of a legitimate, standard business process. In one instance, we observed Excel launching macros, and alerted the customer to the nefarious activity...only to be told that it was a normal, legitimate business process, and expected behavior. Talk about "crying wolf"...what happens the next time something like that is seen in telemetry, and reported? It's likely that someone in the chain, either on the vendor/discovery side, or on the customer's side, is going to glance at the report, not look too deeply, and simply write it off as normal behavior.

The days of opening Task Manager during an engagement and seeing more svchost.exe processes than what is "usual" or "normal" are a distant memory, long faded in the rearview mirror. Threat actors, including insider threats, have grown more knowledgeable and cautious over the years. For more automated approaches to gaining access to systems, we're seeing scripts that include ping commands intended solely to delay execution, so that the impact of commands are not clustered tightly together in a timeline.

There are things...artifacts...that we universally know, or believe we know, to be bad. One of the best examples is the Registry value that tells the Windows OS to maintain credentials in memory in plain text; I cannot, nor have I seen, a legitimate business purpose for having this value (which doesn't exist by default) set to "1". I have, however, seen time and time again where threat actors have created and set this value several days before dumping the credentials. To me, this is something that I would consider to be a universally "bad" indicator. There are others, and this is just one example.

There are things that we believe are highly likely to be bad, such as the "whoami" command being run in an environment. I say, "highly likely", as while I have most often observed this command in EDR telemetry and associated with threat actors, I have also seen those very rare instances where admins had accounts with different privileges, and might have lost track of their current session; typing the "whoami" command allows them to orient themselves (just as it does the threat actor), or to troubleshoot their current permissions.

Finally, we need to be aware that something that might be "bad" might, in fact, be bad for the majority of an environment, but not for one outlier business unit. Back in 2000, I found a persistent route in the Registry on a system; further investigation revealed an FTP script that looked suspicious, and appeared to rely on the persistent route to work properly...I suspected that I'd found a data exfiltration mechanism. It turned out that this was a normal, legitimate business function for that department, something that was known, albeit not documented.

When determining "bad", there's a great deal that comes into play; business processes and functions, acceptable use policies, etc. There's a great deal to consider (particularly if your role is that of an incident response consultant), beyond just the analysis or investigative goals of the engagement. So, "it depends". ;-)

Registry Analysis - The "Why"

Why is Registry analysis important?

The Windows Registry, in part, controls a good bit of the functionality of a Windows system. As such, Registry analysis can help you understand why you're seeing something, or why you're not seeing something, as the case may be.

For example, Registry "settings" (i.e., keys, values, or combinations) can be/have been used to disable Windows Event Logs, enable or disable auditing (the content that goes into the Windows Event Log), disable access to security tools, enable or disable other functionality on Windows systems, etc. The Registry can be used to enable or disable application prefetching, which produces artifacts very commonly used by forensic analysts and incident responders. 

Registry values and data can provide insight into what an analyst is seeing, or why they're not seeing something they expect to see. For example, adding a specific Registry key to the System hive effectively disables logging to the Security Event Log; why clear the log when you can simply stop the event records from being written? Not seeing application prefetching files being generated on a Windows 10 or 11 system? Well, there's a Registry value for that, as well! 

Most analysts are aware that, particularly with respect to the file system, something "deleted" isn't always "gone". This is true for files, but even more so for records (elements with a file), and it's also true for the Registry. However, the Registry can be used to disable functionality the prevents activity from being recorded in the first place. As such, the records are never actually generated, and therefore, cannot be recovered. This is an important distinction to make, as over the past decade and a half, we've seen threat actors actively modify systems within an infrastructure to suit their own needs. For example, disabling or removing security tools, modifying operating system capabilities, and enabling or disabling functionality; whether manually or via a batch file (or some other means), many of these modifications manifest themselves as changes in the Registry. 

Case in point; in the spring of 2019, I was working with incident responders to track activities associated with the Ryuk ransomware group. Looking back to Sept, 2018, we'd seen where the actors had run mimikatz, and then within seconds, moved laterally. Closer examination showed that the actor had modified the Registry so that the operating system would maintain credentials in memory in plain text 6 to 9 days prior to running mimikatz. That way, they didn't have to copy the hashes so that they could crack them; the credentials were already in plain text, so all they had to do was choose the account with the highest level of privileges and move to subsequent systems. This is just one example of how threat actors have modified systems within a compromised infrastructure to meet their needs.

User Activity

In addition to "current state" configuration settings, the Registry "tracks" or maintains a history of activity on the system; updates, upgrades, devices connected, etc. This is also true for user actions; files opened or interacted with, applications launched, WiFi networks connected to, etc.

There used to be a few law enforcement officers who'd contact with me with questions; "used to" because they've since retired. One in particular had worked out a process with me, where she'd share an NTUSER.DAT from an active case and I'd process the hive and give her a comprehensive, detailed list of files interacted with by the user. I'd include applications used, and if applicable, dates and times of the interactions. I'd provide her with a complete description of how this information was found, so that she could replicate my findings so that she could testify (if necessary). She'd then tie the file paths and names to specific files and content, and take that to the pre-trial conference, and very often, she'd end up with a plea agreement.

In 2005, Cory Altheide and I published the first paper to address tracking USB devices across Windows systems. At the time, we were working with Windows XP, and since then, the Windows operating system has grown considerably in the records generated when USB devices are connected, as well as differentiating between various protocols. For example, connecting a smartphone or digital camera to a Windows computer via a USB cable appears in a different manner from a USB thumb drive; connecting a smartphone or a digital camera to a computer can mean the difference between possession and production of illicit images. 

Of course, devices connected via USB doesn't address devices connected via Bluetooth, or Wifi networks to which the computer has been connected.

"Proof of Life", Intent, Sophistication

Information derived from analysis of the Windows Registry can be leveraged to demonstrate "liveness", or to put a suspect "behind the keyboard". In addition, the totality of information derived from Registry analysis can be used to further the understanding of a user or threat actor's intent (what they're after) and their level of sophistication. For example, Registry analysis can show use that the threat actor added an account to a system as a means of persistence, and then added the account to different groups so that the account could be used to access the system remotely via RDP. From there, we can see if the icon for the account was hidden from the Welcome Screen, as well as if additional means of persistence were added.

Also, the timing between the various modifications we observe, in addition to the modifications themselves, can be leveraged to determine attribution. We have observed, for example, some threat actors making use of batch files or VBS scripts to make Registry modifications, either directly via reg.exe, or indirectly via other native tools such as sc.exe, or schtasks.exe. The timing of the modifications, in relation to other modifications and system impacts, can be used to establish attribution; was this truly the threat group we suspect it to be, or someone else? Or, do the observables indicate an evolution of capabilities of the threat group?

We've also seen how RaaS providers embed dozens of preemptive commands in the executables they provide; in the spring of 2020, one RaaS sample contained 156 embedded commands to disable Windows services, via sc.exe and other means. Looking at the timing of the modifications that actually took effect (not all services may be active on the impacted system) alongside files being encrypted provides insight into attribution.

Eco-System

A good bit of what we can find in the Registry aren't things we find as a result of a threat actor or malware directly interacting with the Registry; rather, there are more than a few keys or values that are "indirect artifacts", in that they're generated as a result of the actor or malware's interaction with the "eco-system" (platform, OS, applications, etc.). A good example of this is the AppCompatCache, or "ShimCache"; the entries in the value data are not created as a result of malware directly writing to the value, but rather that the file was on the system and subject to an application compatibility check.

From a configuration perspective, Registry (specific key, value, and data) settings can result in the OS being configured to generate additional "evidence" or tracks as a result of interaction with the eco-system. For example, there are settings to enable additional LSA protections; essentially adding protection to the LSASS.exe process. Setting the capability and rebooting generates an event record (in the Windows Event Log), and then interacting with the process in an incorrect manner will also generate Windows Event Log records (in the appropriate log).

Registry Analysis

Registry analysis is not a stagnant thing. That is to say that you don't reach a point where you're "done", and don't have to go any further. You don't just reach a point in, say, 2018 where you say, "I'm done" and don't continue to evolve your analysis. This is due to the fact that, even in a corporate environment, it's extremely difficult to find two systems that are the same; that is, system "loads" or configurations (base operating system, applications, configurations, etc.) are often very different. As a DFIR consultant, I would encounter different basic loads and configurations with every client, and even within that client, systems had different applications installed (in part, due to mergers and acquisitions), were configured differently, etc. Even when there was a "common load", where every system was supposed to have some common configuration, they weren't; often times, the version of the application would be a rev or two behind others, hadn't been updated in some time, etc.

Also, analysis goals very often differ; what you're looking to prove or disprove will vary depending upon your investigative goals. Are you dealing with a malware infection, a data breach, an insider threat, corporate espionage, access to illicit images or materials, or something else entirely?