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?