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?

On Writing DFIR Books, pt III

Editing and Feedback
When it comes to writing books, having someone can trust to give you honest, thoughtful, insightful feedback is a huge plus. It can do a lot to boost your confidence and help you deliver a product that you're proud of.

When I first started writing books, the process of going from idea to a published book was pretty set...or so I thought, being new and naïve to the whole thing. I put together an idea for a book, and started on an outline; I did this largely because the publisher was asking for things like a "word count". Then they'd send me a questionnaire to complete regarding the potential efficacy of the book, and they'd send my responses to a panel of "experts" within the industry to provide their thoughts and insight.

However, there wasn't a great deal of insight in the responses that came back, and to be transparent, it got worse as the years went on, but again it was part of the process. Having someone to bounce ideas off, and to engage in thoughtful, insightful discussions would have been beneficial, which is why I'm recommending it now.

The same is true when it comes to the tech editing. Early on, one of the tech editors assigned by the publisher would return chapters late (not good when you're operating on a schedule), and even then, the comments would be "needs work" at the top of the chapter; not entirely helpful. So, over time, at first, I just ignored the tech editor comments, until I had built up enough capital as an author to go to the publisher and tell them who I wanted as a tech editor. By that point, I'd already worked with the person and received their agreement. That way, I knew that I had someone on board who would help me and keep me on track, so that I didn't loose the forest for the trees. Just like when conducting an investigation, while writing a book, it can be easy to go down a rabbit hole and go completely off the rails. As such, it's always good to have someone you trust to give you honest feedback during the course of your writing. It's particularly valuable to have someone in the same industry, so that they can provide thoughtful insights toward your writing, as well as make recommendations to help address certain areas or fill in any gaps.

In short, you can and should "take ownership" of the process, as much as you can. I had assumed early on that the publisher had a short list of folks they knew could provide quality edits and insight, but it turned out that they were just "checking the box". You're going to need someone to review your writing anyway, so why not work with someone you know and trust, when all it takes is for you to ask the publisher?

Marketing
Once the book is published, or even prior to that, there's the issue of marketing; how does the community know you've written a book?

Early on, I assumed that the publisher had this all locked up. I didn't see a great deal of "marketing" with the first couple of books, and simply "went with it" when the publisher said that they had a process. After the first few books, I started asking, "...what's the process?" 

At that point, I found that the publisher had a spreadsheet of 101 names of luminaries in the industry, and part of their marketing plan was to send a free copy of the book to each of these folks, hoping that they'd write a review. Yes, you read that right...hoping. None of the recipients was under any obligation to actually write the review. Of the 101 names on the spreadsheet, I only recognized one from the industry, and they had NO INTEREST in host-based forensics; everything they wrote about or discussed was focused on NSM.

A while later, I found out that several authors under the imprint...six of us who all had the word "forensics" in the title of our books...would be attending a significant training event, and it turned out that the publisher had a deal with the bookstore for other such events. However, when I asked, it turned out that the publisher had NO PLANS to take advantage of this opportunity; after all, there were six of us presenting, and having copies of the books at the event would make for a great book signing event, and move a lot of books. I convinced my editor that this would be a great event to attend, and to her credit, she took two days out of her family vacation to bring books to the event; all she had at the end were empty boxes.

So, my point is that when it comes to writing books for a publisher, you may have to take ownership of your own marketing, as well. It's really not hard to do, to be honest, using social media, and getting friends to write reviews of you send them a free copy of the book. Not only is there a lot of great info available on marketing things like a book you've written, there are also a lot of podcasts available, and you can reach out to offer free copies, or to be available for an interview, etc.

Reasons to go looking in the Registry

Chris Sanders tweeted out an interesting pair of questions recently, and the simple fact is that for me to fully answer the question, the tweet thread would be just too extensive. The questions were:

What are the most common reasons you go looking in the Windows registry? What do you use it to prove most?

Like almost everything else in DFIR, my response to the both questions is, it depends. Why? Well, it depends upon the goals of your investigation. What I use the Registry to prove depends heavily on what I'm trying to prove, or to disprove. This may sound pretty obvious, and even intuitive, but far too often in DFIR, we can find ourselves far too easily chasing down rabbit holes that have little, if anything, to do with our investigative goals.

Configuration
The Windows Registry holds a great deal of configuration information, describing what functionality is enabled or disabled, what tools can be accessed, etc. There are many more options available than what we see when we first install the OS; many are not well documented, and many are undocumented. Many configuration settings are described as being accessible through a UI of some kind, and the end result is a Registry modification. For example, many of the settings in the Local Security Policy, as well as GPOs, result in Registry modifications. Several settings accessible via the Windows Security UI also result in Registry modifications.

Another example is that the Registry contains a great deal of information that pertains to the auditing and logging, including not only the audit configuration of the system, but also the Windows Event Logs that are enabled. There's even an undocumented Registry key that, if you add it to the system, the Security Event Log is no longer populated. As we saw with NotPetya, clearing the Windows Event Log only gets a threat actor so far; cleared records can be recovered from unallocated space. However, if the Windows Event Log in question is disabled, then the records are never actually written to disk. This can be very challenging for an incident responder, but it also means that a dearth or absence of Windows Event Logs is no longer a matter a guesswork or assumption; it's trivial to query the appropriate locations within the Registry, and base your findings on fact.

Keep in mind that the breadth of configuration information available in the Registry is dependent upon the use of the system (both the user, and how it's used), as well as the installed applications.

Persistence
When some analysts think of persistence, they think about the Run or RunOnce keys. Why not? These are pretty popular. In 2012, a Google researcher shared that they'd combed across a popular commercial AV web site and found that 51% of the Registry paths led to a Run key. The bad guys use these keys for persistence, because they work, and work reliably.

However, as Hamlet said, "There are more things in heaven and earth, Horatio, than are dreamt of in your philosophy." There are more ways to remain persistent on Windows systems, within the Registry, than just a small handful of keys. Different locations in the Registry allow for programs to be automatically executed on system boot, user login, user logoff, system shutdown, upon the launch of various applications, etc.

Proof of Life
There are a number of Registry keys that contain values that are the direct result of user activity, and can be used to place the user at the keyboard, or not, as the case may be.

Another valuable aspect of the Registry is that in recording user activity, as a means of enhancing the user experience, information about installed and/or executed applications can remain in the Registry, even after the application is deleted or uninstalled from the system. The same is true for files; there are locations within the Registry that will record information about a user's interaction with files that remains long after the file is removed from the system. This is also true for shares and devices; remnants remain well beyond the "lifetime" of the connection.

DEFAULT File
Most folks don't really look in the DEFAULT file (located in the system32\config folder), but Registry modifications made by commands executed via LocalSystem account will end up in this file.

I've seen entries for PSEXEC.exe in this file, I've seen entries added to the Run key in this file, and I've seen where entries added to the Run key further populated the Run keys in NTUSER.DAT files for user profiles created after the value was added to the key in the DEFAULT file.

This particular file can be very interesting simply due to the fact that it's not modified via normal user activity; as such, any unusual or new keys or values that appear in this file should be of significant interest.

Finding New Things
Very often, I will go looking in the Registry to see if there were any changes to the threat actor or malware TTPs, based on previous cases, or from information available via open reporting. By casting a wide net across a finite, deterministic space, you can determine if the threat actor was using the same TTPs observed on previous cases, or if they'd opted for a new technique. 

One of the challenges of relying on open reporting of threat intelligence is that very often, such reporting is not specifically intended for use by DF analysts and incident responders. This is illustrated in the gaps in DF-specific information, as well as incorrect use of nomenclature. For example, this malware write-up* states:

The malware stores its configuration in ‘\\HKCU\Software\Microsoft\Windows\DWM\‘, using registry keys that consist of a uid generated from the serial number of the C: drive and appended with a single digit or character.

Where the statement mentions "registry keys", it should read "values". Some may consider this pedantic, but programmatically, Registry keys and values are very different; their structures are different, the information contained in the structures are different, and the code used to enumerate Registry keys beneath the DWM key is very different than the code used to enumerate values from beneath the same key.

As such I will often pursue examination of the Registry to identify either the malware family, or attribute activity to an identified threat actor (i.e., attribution), or determine if there were any differences between what I was seeing, and the open reporting.

Registry keys, values, and data (or the lack thereof) can provide insight into a threat actors intent, sophistication, & level of situational awareness, as well as provide insight into attribution. Very often, it's not just a single key or value, and context is king!

Conclusion
There are basically two ways to go about digging into the Registry; casting a wide net, or intentional extraction. As Boris the Animal said in MiB3, "I prefer to do both." By automating both techniques, it's a relatively simple process to validate previous findings and open reporting, as well as find new things. The key, however, is that this is a living, continual process, as new findings are baked right back into the process.

While this blog post is not all-inclusive, I wanted to take a shot a providing a more comprehensive response to Chris's questions than would make sense in a long series of tweets.

*To be fair, my pointing out the above malware write-up is not single out the author; not at all. Microsoft is widely known for making this mistake a great many times, in their own write-ups, and we see this quite a bit more than I'd like to admit in open reporting.

Tips for DFIR Analysts, pt VI

Context & Finding Persistence
I was looking into an unusual mechanism for launching applications recently, and that research brought back a recurring issue I've seen time and again in the industry, specifically pivoting from one data point to another based on knowledge of the underlying system.

Very often, during SOC monitoring or live response, we'll find a process executing via EDR telemetry (or some other means) and have no clear understanding of the mechanism that launched that process. Sometimes, we may have the data available to assist us in discovering the root cause of the process launch; for example, in the case of processes launched via web shell, all you need to do is trace backward through the process tree until you get to the web server process (i.e., w3wp.exe, etc.).

Other times, however, it's not so easy to do this, as the process tree proceeds back through the parent and grandparent processes with no clear indication of the source. In such cases, we may need to seek other sources of data, such as Windows Event Log records, to determine a system boot, or a user login to the system. Then, we may need the Windows Registry hive files, or file system data, to determine persistence mechanisms. What this means is that understanding the context of a suspicious process can help us pivot to determining the origin of the process launch, and that context can be determined by an event's proximity to other events.

Tools
Over time, I've seen tools...forensic analysis suites...evolve and include more "things". For example, Paraben's E3 application (version 2.8) includes parsing of data from the Registry, and I've seen analysts use Magnet Axiom to do something similar. ForenSafe blogs about the ArtiFast application, including screen shots of the information available from the Registry. This is all in addition to tools that specifically parse various data sources, such as Eric Zimmerman's Registry Explorer, and other tools.

What analysts need to remember is that these are just tools; it is still incumbent upon the analyst to correctly interpret the information presented by the tools. For example, this ForenSafe article discusses printer device information available in the Registry, and it appears to present the information for the analyst to interpret (as many tools do). How would you, as an analyst, use this information to determine if the printnightmare exploit had been used by a threat actor, or if a threat actor had enabled the "keep print job" functionality on the printer, as a means of staging data for exfiltration?

This JumpSec Labs article does a good job of discussing data sources and tools that can be used in the absence of Windows Event Logs. However, there are a couple of items that do need to be mentioned; for example, artifacts should never be viewed in isolation from each other, as context is missed. In the article, the author mentions the use of Prefetch files, and then the AppCompatCache/ShimCache, to demonstrate program execution. Rather than being viewed separately, these should be viewed together whenever possible. The reason is that 32-bit Windows XP was the only version of Windows where the AppCompatCache data recorded a second time stamp, indicating the time of last execution; in all other instances, the available time stamp is the last modified time extracted from the $STANDARD_INFORMATION attribute within the MFT. I've seen cases over the years...not just my own cases, but also investigations discussed during conference presentations...where the threat actor placed the EXE on the system and "time stomped" it before executing it. In one instance (shared at a conference in 2015) the misinterpretation of this data had a profound, negative impact on the "victim", as it was a PCI case and the "window of compromise" was 4 yrs, rather than a couple of weeks.

All of this is to say that I highly recommend the intentional, purposeful use of tools to further forensic analysis. However, at the end of the day, it is still incumbent upon the analyst to correctly interpret the data presented by the tools, and this interpretation is often heavily impacted by the completeness of data collection and parsing.

Artifact Constellations
As discussed the JumpSec Labs article, analysts may encounter systems upon which some data sources are not readily accessible. The article describes threads that analysts can pursue in the absence of Windows Event Logs, but something the article doesn't touch on is "artifact constellations"; that is, when some action occurs on a system, there are often secondary and tertiary artifacts created that, when considered together, provide much greater evidence of activity.

Articles like this one do a great job of illustrating some of the different artifacts available, but it is still up to the analyst to complete the constellation, and to correctly interpret the data. 

Spelling & Grammar
Take spelling and grammar seriously. I know a lot of folks don't, and that when someone points out poor spelling, they're referred to as the "grammar police" or as a "spelling Nazi". 

However, consider this...let's say you work for me, and don't care about spelling or grammar. Now, I have to review EVERYTHING you produce before it goes to the next level, be it an internal executive or a customer. I know that every time you send me a report or an email via Outlook, it's going to be full of words with red squiggly underlines...you know, MSWord's way of saying, "hey, you misspelled this word...". Once those are corrected, I still have to spend a great deal of time reviewing what you wrote, because now I have to deal with incorrect grammar, incomplete sentences, and correctly spelled but incorrect words.

Let's reduce it a little bit...what happens when you transpose an IOC? Let's say you transpose an IP address or a domain name to be blocked, and you misspell it...what happens then? Well, the IOC intended to be blocked isn't, and the organization isn't any better off;  in fact, it's worse because everyone thinks the correct IOC has been submitted. 

What happens when you misspell a Registry value name (or the data) for a setting on a critical system? The system doesn't recognize the value (or data), and the intended functionality is not applied.

Apply the same thought to threat hunting, either as part of a proactive threat hunt or a DFIR threat hunt. Or, if you're looking for an IOC in logs...either way, you misspell it and report, "...nothing found...", what's the result?

Now, let's look at it another way...I work for you, and I'm the one who's not spelling things correctly. In what position does that place you?

Threat Hunting, IRL

While I worked for one company, I did a lot of public speaking on the value of threat hunting. During these events, I met a lot of folks who were interested to learn what "threat hunting" was, and how it could be of value to them.

I live in a very rural area, on just shy of 19 acres. One neighbor has 15 acres up front and another 20 in the back, and he adjoins a large property with just a trailer. My neighbor on the other side has 19 acres of...just 19 acres. We have animals, as well as more than a few visitors, which makes for a great analogy for threat hunting.

Within the borders of my property, we have three horses and a mini-donkey, and we have different paddocks and fields for them. We can restrict them to certain areas, or allow them to roam freely. We do this at different times of the year, depending upon weather, availability of hay, etc. For example, in the spring, when the grass is coming in really well, we don't want the horses on it too soon or for too long, because they can colic (which is a bad thing). And we may want to cut the grass (do maintenance), so we'll restrict the horses from that area.

I understand the normal comings and goings of the horses, because I have full visibility. I can not only see most of the areas (albeit not all) from the house, but I get out and walk around the property. I am familiar with the normal habits of the horses, and understand how they respond to various "events". I also know when something is amiss, simply by watching the horses. This is my "infrastructure".

Like most horse owners, we provide them with salt and mineral licks, in the form of 40 lb blocks. We make this available to them year-round, replacing blocks as they get diminished. Even so, we've also notices that the horses will scratch at certain spots on the ground, and then spend a good bit of time happily licking the ground. Knowing this, we try to keep up on "pasture maintenance"; we pick up the poop, or drag the field, so that the horses don't get worms. We also know what the spots look like, and that they're different from where the horses like to roll. Where they scrape and lick, the ground is bare, and there are usually rounded marks where their hoof initially contacts the ground, before they drag it across the ground to break up the earth. Where they roll, there is usually still some semblance of grass left, and there's also hair left. In addition, the marks from their hoofs, where the horses circle before laying down and then when they get back up, are different from where they scrape the ground. All in all, this is normal, expected "user behavior". 

Walking the dog around the property this year, I noticed something I haven't seen before...there are bare spots on the trails where the leaves and grass have been scraped away and the ground exposed. This seems very similar to what I've seen the horses do, however, there are differences. First, these spots are in areas that the horses do not usually frequent unless we're riding them. Second, instead of rounded hoof marks, there are distinct two-toed marks in the ground. Third, these exposed areas are usually much smaller than what I've seen associated with the horses. From what I've observed, these are deer doing the same thing as the horses, and if the only IOC someone shared with me was "bare spot on the ground", I would assume that it was most likely from the horses (i.e., normal user activity). However, if I look beyond the IOC, and look at the specifics of the activity (i.e., TTPs), I'd then be able to clearly differentiate between "normal user activity" and "potentially unwanted/malicious activity". 

My neighbors recently shared "threat intel"...they'd seen a bear on their property. Now, they'd done more than just stated, "hey, we saw a bear!" That's right...they did more than just share an IOC. In fact, they took a picture, indicated the time of day, and the picture gave an indication of where the bear was located on their property. So we had other things to consider than just "a bear"...size, color, type, direction of movement, etc. As a result, I'm now on the look-out for these TTPs, as well as others known to be associated with this particular threat; scat, claw marks on trees, etc. We have persimmon trees in the area, and while I have seen scat from various animals that contains persimmon seeds, I have yet to see bear scat. But I am aware of the "threat", and looking for clear indications of that threat.

My neighbors did more than just share an IOC, they shared clear TTPs, and enough of it such that I could search for indications of that threat within my infrastructure.

We've lived on this property for more than 4 1/2 yrs, and it's only been in the past year that I've found two turkey eggs. In both cases, they've been broken, and based on the condition of the eggs, I can't tell if the chick hatched, or if the egg was a meal for a raccoon. Regardless, it does tell me that there are very likely turkeys in the area. While we are knowledgeable and understand the nature of turkeys and the "risk" they bring to the "infrastructure", the horses have a completely different view. To the horses, a turkey scurrying through the underbrush may as well be a velociraptor released from it's cage, right out of Jurrasic Park. While sitting in my office, a turkey is not a threat to me; however, while I am on horseback, a turkey could be a "threat", in that spooking the horse I am riding might have a severely negative impact on my day. I have another threat that I'm aware of, and because I have detailed visibility of my environment, and because I understand the nature of the threat, I understand the risk.

For me, it's interesting to take a step back and look at how my IRL life parallels my work life. Or, maybe my IRL life is being viewed through the lens of my work life. Either way, I thought that there were some interesting parallels.