DefCon 2018 CTF Plus

I don't often engage in CTFs. Yes, they're fun, but even when an effort is made to have various aspects or stages be representative of real-world use cases, overall, they don't tend to hit the mark.  I've done some of the various challenges, and once or twice been part of the test team for CTF challenges.

Not too long ago, I ran across David Cowen's blog post for the DefCon 2018 CTF.  I wanted to run through at least the first image, but I didn't want to sign up for the challenge...I was just hoping to find the scenario or questions.  Phill pointed me to Google, and I found a couple of sites that included the individual questions, along with responses (HackStreetBoys, InfoSecurityGeek, Caffeinated4n6).

If you look at the questions answered at each of the linked sites, you'll see that there are some commonalities in answering the individual questions in the CTF, and in other cases, there are a few differences.  One example of differences is for the question, What was the name of the batch file saved by mpowers? The HackStreetBoys opted to use the MFT, while Caffeinated4n6 went with Registry Explorer.  I chose to use the RegRipper comdlg32.pl plugin, and we all arrived at the same answer.  This is not to say that one method was better than another, as we all got to the same correct response.

However, IRL, this isn't likely where things will stop.  In my experience, there haven't been many (re: none) customers who have asked me to simply determine the batch file that a user saved, and leave it at that; with real-world DFIR, there was always something more to it.  As such, I decided to use the question (the one about the batch file being written) as a starting point, and build out an analysis approach that was a bit closer to the sort of thing that you would see as a DFIR consultant, or even as an analyst in an FTE position within a company.

We can see in a timeline of overall system activity when the batch file was created:

Mon Jul 23 16:15:06 2018 Z
  FILE    - .A.B [169] C:\Production\update_app.bat

We can also see when the file was last modified:

Mon Jul 23 17:35:35 2018 Z
  FILE    - MA.. [48] C:\Users\mpowers\AppData\Roaming\Notepad++\backup\
  FILE    - M... [169] C:\Production\update_app.bat

Taking a look at the MFT record for the file, we can confirm this:

166116     FILE Seq: 4    Links: 2   
[FILE],[BASE RECORD]
.\Production\update_app.bat
    M: Mon Jul 23 17:35:35 2018 Z
    A: Mon Jul 23 16:15:06 2018 Z
    C: Mon Jul 23 17:35:35 2018 Z
    B: Mon Jul 23 16:15:06 2018 Z
  FN: UPDATE~1.BAT  Parent Ref: 165091/2
  Namespace: 2
    M: Mon Jul 23 16:15:57 2018 Z
    A: Mon Jul 23 16:15:06 2018 Z
    C: Mon Jul 23 16:15:57 2018 Z
    B: Mon Jul 23 16:15:06 2018 Z
  FN: update_app.bat  Parent Ref: 165091/2
  Namespace: 1
    M: Mon Jul 23 16:15:57 2018 Z
    A: Mon Jul 23 16:15:06 2018 Z
    C: Mon Jul 23 16:15:57 2018 Z
    B: Mon Jul 23 16:15:06 2018 Z
[$DATA Attribute]
[RESIDENT]
File Size = 169 bytes

A couple of other bits of information from the MFT record...it doesn't appear as if the file was time stomped, and the file is resident within the record.  This isn't surprising, given the size, but it would have an effect on our ability to recover indications of the file, should it be deleted.

Creating a micro-timeline using the mpowers UserAssist, RecentApps, and RecentDocs Registry entries, and IE browser history, we can get a good bit of additional detail regarding just that user's activity.  Pivoting into that micro-timeline with the name of the batch file, we can see from the comdlg32.pl plugin the date/time when the batch file was accessed by the user:

Mon Jul 23 16:48:15 2018 Z  
  REG     mpowers - ComDlg32: OpenSavePidlMRU\bat - My Computer\C:\Production\update_app.bat

Continuing to search the micro-timeline for indications of the batch file, we see:

Mon Jul 23 17:35:53 2018 Z
  REG     mpowers - [Program Execution] UserAssist - C:\Production\update_app.bat (3)
  REG     mpowers - C:\Production\update_app.bat (3)

In short, not only do we see the file being created and saved, but we can see that the file was executed.  This is huge!  A batch file, or even malware, sitting on a system is harmless.  It doesn't do anything until its launched or executed. Viewing the contents of the batch file within FTK Imager, we can see that it includes two copy commands, each of which copies a file from a Z:\ volume to the C:\Production folder.  Incorporating the user-specific timeline information into an overall timeline of system activity as an 'overlay', or using it as a pivot point into the system timeline, we can see the effects that the batch file being executed has upon its overall eco-system (the server file system, Registry, Windows Event Log, etc.)

Using the contents of the batch file as a pivot point, we can see from the micro-timeline of user activity that the mpowers user accessed the Z:\ volume pretty extensively. But where does that volume come from?  Is it a USB device?  Checking the Software and System hives for indications of connected USB devices reveals that there isn't a great deal of information available to indicate the use of a USB device.  How about a mapped share?  Our micro-timeline reveals the following:

Mon Jul 23 16:01:14 2018 Z
  REG    mpowers - ShellBags - Desktop\My Computer\Z:\project_0x02\tcontinuous\dist

Mon Jul 23 16:00:53 2018 Z
  REG    mpowers - Map Network Drive MRU - \\74.118.139.11\M4Projects

While not directly conclusive, the timing of the above events is close enough that we may be able to reasonably tie the mapped folder to the Z:\ volume.

Further, we still have a good bit of information about the batch file itself.  Looking at the micro-timeline, and pivoting on the batch file name without the extension, we see references to update_app.ps and update_app.ps1, both apparently located (per the mpowers micro-timeline) in the C:\Production folder. However, viewing the image via FTK Imager, neither of those files appear in that folder.  Searching the overall timeline of system activity similarly provides no indication of the files.  These look like they may be PowerShell scripts, but again, we don't see them in the 'active' file system within the image.

Checking the contents of the mpowers ConsoleHost_history.txt file, we see the following:

cd C:\Production\
dir Z:\project_0x02\tcontinuous\dist\
dir Z:\project_0x02\tcontinuous\production\
copy Z:\project_0x02\tcontinuous\production\tcontinuous.exe C:\Production\
$PSVersionTable.PSVersion.toString()

Much like a .bash_history file on Linux systems, the ConsoleHost_history.txt file does not contain time stamps. However, it does provide some useful information, in this case indicating that there was some use of PowerShell by the user.  Knowing that, and knowing that PowerShell scripts were likely associated with the user, we can create a micro-timeline of PowerShell events, which requires only two commands (note that I've already extracted Windows Event Log files from the image):

wevtx.bat f:\defcon\files\*powershell*.evtx f:\defcon\files\ps_events.txt

...and...

parse -f f:\defcon\files\ps_events.txt > f:\defcon\files\ps_tln.txt

As a result of the commands, we have a good bit of information available to us from the Windows Event Logs, and it is much easier to go through than if we had a full timeline of all system activity.  For example, we can easily see clusters of PowerShell/600 events beginning at Mon Jul 23 16:27:51 2018 Z, which include the following:

HostApplication=Powershell.exe -ExecutionPolicy Bypass C:\Production\update_app.ps1

Ah, okay...so it appears that PowerShell was used to attempt to launch this file; our assumption that the .ps and .ps1 files were PowerShell scripts is in the process of being confirmed.  However, at the same time, we also see a PowerShell/300 (warning) event that states:

Could not find the drive 'Z:\'. The drive might not be ready or might not be mapped.

Hhhhmmm...for whatever reason, the script seems to have had issues, and possibly not worked.  This may be the reason why the user resorted to a batch file.

But wait...there's more...

Mon Jul 23 17:55:30 2018 Z
  REG    - M... HKLM/Software/ROOT/Microsoft/Windows NT/CurrentVersion/Schedule/TaskCache/Tree/Update App  
  FILE   - .A.B [3874] C:\Windows\System32\Tasks\Update App

From the above we can see that a Scheduled Task was created, and viewing the contents of the XML file, we can see that the task contains the command "C:\Production\update_app.bat".  Shortly thereafter, we see:

Mon Jul 23 17:57:17 2018 Z
  FILE   - .A.B [742400] C:\Production\tthrow.exe
  FILE   - .A.B [5425251] C:\Production\tcontinuous.exe

Okay, there are the files that were the targets of the 'copy' commands.  Shortly after these events in the timeline, we see:

Mon Jul 23 18:07:14 2018 Z
  FILE   - M... [474] C:\Users\mpowers\AppData\Roaming\Microsoft\Credentials\F03B2BF5CC26D5309225478FE717BB7E
  FILE   - M... [1806] C:\Windows\debug\PASSWD.LOG
  REG    - M... HKLM/Software/ROOT/Microsoft/Windows NT/CurrentVersion/Schedule/CredWom/S-1-5-21-2967420476-1305424719-3994513216-1000 
  FILE   - M... [3872] C:\Windows\System32\Tasks\Throw Taco

From the above, we can see that the "Throw Taco" Scheduled Task XML file was modified.  The XML contents of the "Throw Taco" Scheduled Task includes:

C:\Production\tcontinuous.exe
tthrow.exe 74.118.139.11:7420

This gives us some information with respect to our two mystery files, the relationship between them, and how they were used (i.e., one was an argument for the other, and they were run with SYSTEM-level privileges).  But what about the other entries in the timeline, at the same time?  The Registry key that points to "CredWom" includes the SID for the mpowers user, and the last entry in the passwd.log file reads:

07/23 11:07:14 Attempting password change server/domain 

WIN-29U41M70JCO for user mpowers

So, at this point, we haven't done actual malware RE on the two mystery files, but we do have a good deal of valuable information for an analyst.

Pivoting back to the Scheduled Tasks, we can develop a good view of task execution activity (or history) by using wevtx.bat to parse the Task Scheduler Event Log file into an events file, and then create individual events files for each task using 'find'.  From there, using parse.exe to convert the individual events files into micro-timelines gives us the available execution history for the tasks.

Summary
What started out as a straightforward CTF question developed into a much fuller investigation, using timelines (full, micro), overlays, and pivot points, all in order to build out a pretty interesting picture of activity on the system, around not just the user saving the batch file, but the use of the batch file and the relationship to other activity on the system.

Something else of value you can use from the AmCache.hve file is the following:

Mon Jul 23 17:39:12 2018 Z
  AmCache  - Key LastWrite - c:\production\tthrow.exe (5267b1da851ce675b1f07e0db03fe12eb51ec43e)

Mon Jul 23 17:25:36 2018 Z
  AmCache  - Key LastWrite - c:\production\tcontinuous.exe (ad2134b5ad9ed046963c458e2152567b6269235f)

Now we have hashes, and in this case, links to VT detections (which won't always be the case).

We've also seen is the value of knowing the version of Windows you're working with; in this case, Windows Server 2016 DataCenter.  This informs us as to things such as the version of PowerShell installed (version 5.1.14393.1884), and that the PowerShell Event Log records would be much more inclusive than they were on Windows 7.

The CTF image provides other interesting opportunities, as well, such as working with Volume Shadow Copies, recovering deleted data (from unallocated space, Registry hives, etc.), working with Registry transaction logs, using hindsight to parse a user's Chrome history, etc.

Take-Away
A big take-away from this analysis walk-thru, for me, is that micro-timelines, overlays, and pivot points are extremely useful during analysis.  Windows systems are very noisy and verbose, and taking a minimal view of different data sources so that you can begin orienting yourself helps cut through a lot of that noise.  A timeline creation process that isn't completely automated provides room for processes that allow the analyst to target specific data sources and develop mini-timelines, and in turn, pivot points.

As an example, the BITS Client Event Log file from the system image has a number of event records, but none of them necessarily have anything to do with the investigation itself, but rather with Windows and Chrome updates.  This also means that data sources such as file system metadata, Windows Event Logs, USN change journal, and possibly even the Registry are going to contain a lot of events related to those updates.  As such, creating an overall system timeline, but then using micro-timelines to develop pivot points into the overall timeline will allow for iterative, targeted analysis.  Developing micro-timelines and then using what's gleaned from them to pivot into the overall system timeline for context is a great way to build out an investigation, and provide the basis for your analysis.

Final Words
I wanted to give a huge thanks and shout-out to David and Matt for putting this CTF together!  It's a lot of work to put together a CTF with just minimal artifacts, and they did so with three full images!  Thanks so much for making these available!

Deep Knowledge, and the Pursuit Thereof

When IR was largely DF-related work, relatively few in the industry held deep knowledge of artifacts.  Over the years, IR has moved from "image all the things" to "find and image the impacted systems" to "let's deploy an enterprise agent or sensor and collect data from all the things".  As the need for enterprise-wide response became more evident, we developed concepts such as "triage", or collecting specific, targeted data from systems to make a decision as to whether they were "in scope" or not.  We adapted concepts such as "sniper forensics", seeking out that targeted data, from disk forensics to the enterprise.  As we've moved to this enterprise-scale response, including deploying sensors, agents, and automated means of data collection and parsing, we need to ensure that we continue to progress beyond where we were before, in that practitioners can be even further removed from developing a deep knowledge of the data.  This isn't to say that this is the case for all analysts; being absolute would be both incorrect and pointless. 

As tools and frameworks have been specifically designed for addressing the enterprise issue, deep knowledge of systems and artifacts can potentially remain with a few, rather than opening the door and extending that knowledge for the many. As practitioners, we have to be wary of tools and frameworks blinding us to the deep knowledge of the nature and context of the data itself.

Many, many moons ago, back when I was QSA-certified and conducting PCI examinations (ssshhh...don't tell anyone...), our team was using a commercial forensic suite to perform searches across acquired images for credit card numbers (CCNs).  Our assumption was that the commercial product performed as advertised, in that it found "valid" CCNs, per the definition of the PCI Council (which, at the time, was Visa).  We had three checks at the time...BIN, length, and Luhn...and if the CCN that was found passed all three, it was passed along to the appropriate card brand for verification.  At one point, we had a case for which we knew CCNs from two specific brands had been used, but running the commercial product produced no results for those brands.  Our initial query with respect to what the product considered a "valid" CCN resulted in a link to a wiki page on credit card numbers, but did nothing to explain why we weren't received the expected result.  Finally, a deeper investigation, which included further questions and no small amount of testing, revealed that the product at the time did not consider some valid CCNs to be "valid".  Rather than waiting for the core, underlying code to be updated, we opted to go with 7 distinct regexs; while this slowed the search process down, it did give us the needed capability.

My point is that all of this came from a few analysts who were close to the data, and had 'deep knowledge' of the artifacts.  Or, at least deep enough to know where they needed to go deeper than what the tool was presenting.  At the time, this was not something that was plastered all over the Internet; no, it was these few analysts who were looking at the issue, and subsequently, wondering what else had been missed.

When I first released RegRipper over a decade ago, my intention was for it to be a community-based tool.  There was one thing that I was absolutely sure of...I would never see everything there was to see, even in the Registry, nor would I know everything there was to know.  As such, I wanted to provide a means by which analysts could either write their own plugins (some did, starting with copy-paste...) and share them with the community, or reach out and share data so that a plugin could be written or updated.  Over the years, more than a few have done so, but for the most part, those who use the tool do so by downloading and running it.

In 2013, Corey Harrell released auto_rip, a tool that brought a modicum of automation to RegRipper. In releasing it, Corey stepped on to the path of sharing his thought process when it came to analysis; in auto_rip, Corey shared how he structures the collected data for analysis, moving RegRipper from a point-and-fire tool to one used to take a targeted approach to data parsing and presentation. Much more recently, Silv3rHorn released autoripy, in part because auto_rip hadn't been updated in some time.

Nuix has a free extension for their Workstation product for automating the use of RegRipper (and one for Yara, as well), and automatically incorporating the results directly into your Nuix 'case'.  This extension automates almost all of what an analyst would need to do to run RegRipper; it automatically locates the hives (independent of the version of Windows), and runs plugins based on the profiles for each hive.  But remember, I said, "almost".  The analyst has to download RegRipper themselves, as well as ensure that the profiles for each hive are updated, based on the currently available plugins.  This is easy enough to do, as the command line tool for RegRipper (i.e., 'rip') includes a switch for automating this process.  But this isn't something that the extension does; to make the best use of the extension, the analyst needs to do just a little bit more work. 

The question then becomes, are you doing it?  Or are you downloading RegRipper and running it via the extension, with no modifications?  Are you pulling everything you need for your case from the Registry hives, or are you relying on the tool to do it for you?

While I have a great appreciation and fondness for automation, and respect for the effort that goes into creating automation, my concern with regard to tools such as RegRipper, log2timeline, plaso, KAPE, etc., is that rather than pulling back the "veil of mystery" and making the data more accessible (and therefore, more within their realm of knowledge) to the analyst, and thereby increasing deep knowledge in a much wider range of analysts, the result is the opposite. Instead, are we allowing automation, particularly at the enterprise level, to add additional layers of abstraction between the data and the analyst?

Don't get me wrong...I'm not bashing tools such as plaso, KAPE, or any other tools like them.  Not at all.  If it makes someone's job easier and more efficient, that's awesome.  It doesn't matter if it's a full-blown compiled application or a batch file...if it works, so be it.  All of these things are wonderful.  But as practitioners, we have to be careful about how we view and use the tools. 

A side effect (or ancillary effect, depending upon how you look at it) of this is that the community has weaponized terms like 'expert' and 'authority'.  These terms are used to set their designees apart, unreachable and untouchable.  "They're the expert, so all of the functionality I would need must be included in that tool that they released for free, and it's not something I need to concern myself with."

Circling back to RegRipper, I don't know everything there is to know about the Windows Registry, and I certainly don't have any insight into your analysis goals, nor the data you're currently examining.  If you've updated RegRipper with the latest set of plugins, there's no guarantee that there are plugins that will extract and parse the data pertinent to your case.  There may be a plugin that parses data from an older version of that application the user launched, but it hasn't been updated in 8 years.  Or maybe the user used an application for which no plugin exists.

Tool and framework development is great; what better to make your work go quicker, more efficient, and less error prone than automation?  And I don't expect that all of a sudden, everyone will know everything; again, that just doesn't make sense.  However, as practitioners, we shouldn't rely on these tools and frameworks to automagically provide all of the data needed for our case, parsed and displayed for our analysis.  Instead, we need to be vigilant, and ensure that we're looking at such things with a critical eye.

My hope is that more folks in the DFIR industry will use these tools and frameworks as a means to develop deeper knowledge of the data and artifacts, rather than an excuse to not do so.

Being a DFIR Speaker

Brett recently posted a very good article on the three fears folks encounter when comes to public speaking in DFIR.

Reading his article, and re-reading it, got me to thinking about my own experiences.  My first experience speaking in DFIR was at LISA NT 2000; however, it wasn't my first public speaking experience.  I'd taken a required public speaking course in college, and like most folks in college, did what I could through the course, did a brain dump on the exam, and walked away from the material.  That was a mistake.  I was headed into the Marine Corps, and guess what...they put each and every one of us on the hot seat, over and over again.  It began with the "impromptu speech" exercise in Officer Candidate School, where we were each given a few minutes to put together a short speech on a topic that the platoon commander gave us, and we had to give that presentation in front of the rest of the platoon.  No props, no PowerPoint, no finger puppets...just put together and present a concise, coherent presentation.  This training continued the following summer after commissioning as each of us went through The Basic School; for example, there was an evolution of instruction called "techniques of military instruction", where we each had to give a short presentation after choosing from several topics, such as "field sanitation".  Throughout the six months of training, we were constantly giving presentations...patrol orders, and other 5-paragraph orders.

When I returned to The Basic School as an instructor, I had to go through the process called the "murder board"...I had to give the classes I would be presenting in front of the rest of my team, which included other LTs, Capts, and the Major in charge of our group.  After that, there was continual process improvement, as I gave the various classes and presentations to student companies (2ndLts and Warrant Officers), and processed their instructor review forms from each class.

So, yeah...I had a good bit of practice.  Some of the feedback was constructive.  In other instances, the feedback was purposely negative, so that we'd get used to receiving negative feedback.  However, when I was standing on the podium for the first time, giving my first presentation in front of a technical audience in the private sector, I was already pretty beat by the time I got there...the anxiety from my imposter syndrome had kept me amped for so long, I was pretty tired by the time I said, "hello" into the microphone the first time.

Another opportunity I had to present at a major conference was in New Orleans; the conference organizers thought it would be a good idea to hold the conference during Mardi Gras.  This was both a good and bad idea at the same time, because it gave folks something to do besides the conference.  One I was accepted to the conference, I was really looking forward to meeting and engaging with a couple of the folks who would be teaching training courses before the conference...but that ended up being a non-starter, as several of them disappeared into the party crowd the moment their course was complete.

When it came my time to speak, I dutifully got the room a few minutes early to ensure that the AV was suitable, I had the right connectors (VGA, at the time) and everything was set up.  When the time came for me to speak, I looked up and all I could see, in the entire room, was the folks recording the video for the talk, and their lights.  I quite literally could not see anyone else in the room, and was just about to cancel the talk when I realized that there were actually four people in the room besides me, and the video crew.  However, they'd all decided to sit behind the stadium lights the video crew was using, and I couldn't see them.  I ended up giving the presentation to what I assumed was all four people...the door in the back of the room may have opened and closed once or twice during my talk, I don't remember.

Some things that I've found over time are good to prepare yourself for...

There's always going to be someone asking what seems to be out-of-the-ballpark questions.  When the question gets asked, your mind is going to be racing to understand the question and apply it to the context of the presentation and conference.  You'll have just spent weeks, or even months, preparing the materials, and even practicing your presentation.  And you'll have just spent 45 minutes or more, with your mind racing while you were speaking...are you hitting all of your points, are you saying what you wanted to say, oh, god I'm not really reading directly from the slides, am I?  Sound exhausting?  It is.  And you'll get that way-out-beyond-left-field question. 

My recommendation...rather than trying to do a pretty massive context switch on the fly, just say that you'll take it off-line.  Don't get into a back-and-forth right there, because it'll just chew up time and others won't be able to ask their questions.  Or, in the case of presentations just before a break, or lunch, or the end of the day, get to whatever's next.  Besides, it's better to be able to focus your attention on those types of questions when you're not on the podium.

Similar to this is the "...what happens if you..." or "...did you do this..." question.  I remember years ago I was presenting at a conference on NTFS alternate data streams, and I ran through the litany of examples, only to get, "...did you try this?"  If you're confident in the material and the Demo Gods are kind to you that day, there's nothing wrong with opening a command prompt and giving it a shot.  After all, I strive to learn something new from the perspective of others, when I have the opportunity, and this is a good way to go about it.  However, in this case, the question was a "...what happens if you...?" question, and I turned it around...I knew the person asking the question had a Windows laptop open in front of them, so I asked, "...why don't you try it and let us all know what you find."  Now, this wasn't intended to put that person on the spot, nor to single them out.  The purpose of my responding what way was to demonstrate that when the conference was over and we weren't all in the room together, it's possible to get the answer to our questions by simply trying these things ourselves.

Another aspect of this is the smartest person in the room.  You know who they are, because you've seen them at conferences, just like I have.  These are the folks who have a question, stand up, and the first word out of their mouth is "I", and they don't actually ask a question.  Whether they intend it or not, their delivery is going to come across as, "look how much I know" or "look at how smart I am".  Now, I'm not suggesting that this is the intention, I'm simply saying that this is how it comes across, and the best way to handle these situations is to thank them, and maybe follow up with them later in the conference. 

Then there's the long-winded talker who takes the opportunity, once they have the mic and everyone's attention, to abscond with it.  Yes, its exactly how it sounds...there will be someone who "runs away" with your presentation once they have the microphone.  This is another one of those, "...let's take this offline..." moments. 

There are going to be people who ask the question you just answered.  Literally.  I've been to conferences (attended, as well as been a speaker...) where speakers have to submit their presentations prior to the conference date.  The presentations are provided on a CD/DVD, or at the conference web site.  In more recent years, this has all been part of smartphone apps for some conferences; everything, including the schedule and presentation materials are available via the app.  When it comes time for you to speak, the person from the conference who introduces you will usually make a statement about where the presentation materials can be found, and some speakers may also have a URL in their presentation (maybe at the beginning, usually at the end) as to where the slide deck or materials can be found.

And yet, there will still be someone who asks if the materials will be available, and if so, where/when.  It happens.

What I've seen more recently is that even though presentation materials are available, attendees will use their smartphones to take pictures of slides.  I'm not at all sure why people do this if the materials are available, but from my perspective as a speaker, it simply tells me that they aren't interested in what I have to say.

Final Words
I don't for the life of me believe that anything I've shared here today is isolated to the DFIR community.  Not at all.  I am sure that these same sorts of things happen in other communities and at conferences of all types.  However, I'm sharing what I've seen over the years in hopes that it will help others as they prepare to venture forth and engage in speaking at conferences.  If it's a good experience for the speaker, they're more likely to continue.  Good luck.

Lessons From Time In The Industry

I recently had the opportunity to give a presentation to the class taught by a good friend of mine.  She'd asked me well in advance, and over the weeks leading up to the presentation, I went back and forth on the subject matter...what would I talk about to a group of folks just coming into the industry?  I ultimately gave a presentation on Registry analysis, but I had compiled some notes on various other topics, including one of which I'd titled, "Lessons Learned In The Industry".  By the time we got to the presentation, I had more than a few pages of notes, with edit marks, sticky notes, and I'd even written up a couple of Word documents that were now sitting on my desktop.

Instead of crumbling the notes up and deleting the Word docs, I thought it might be a good idea to get the notes written out into some semblance of a presentation, and blog post was as good a place to start as any.  Also, this gives me the opportunity to put something down in writing and edit it, hopefully making it into something that makes a bit of sense before publishing it.

A little bit about myself to provide some context; I started in "information security" about 30 years ago.  If I had to tie my time in the field back to a single point in time, my first real introduction to 'security' came in my initial military training.  This training didn't involve computers, but had to do with information security overall.  A lot of the training involved terrorism awareness (i.e., unusually heavy or dense packages, misspelled names or addresses, stains on packages, etc.), cryptographic equipment, communications security, authentication, etc.  All of this maps directly to the 'cyber' realm today, except for perhaps the issue of misspellings.  As a community, we've gotten to a point where misspellings and issues with grammar are accepted as the norm.

Getting Started
We all start someplace.  I started down the road of computer-based information security while I was in graduate school.  As I've mentioned before, I was in grad school at a very interesting time for the computer industry.  Not only was I attending school on the outskirts of Silicon Valley, but new versions of operating systems were coming out (Windows 95, Windows NT, OS/2 Warp, etc.), and some network security tools (SATAN) were just being developed and released.  After finishing my degree program, I took a class in Java programming out of SJSU, in which the professor spent a lot of time talking about "shippable places".  This is all to say that there was a lot going on in the industry at the time, and a lot of different paths one could follow.

All in all, these were very interesting times, and I was in an very interesting place.  Things were no more or less interesting than they are now, just different.  I was transitioning from military to civilian life, and needed to find "my place", and like many who are just coming into the industry, there was a LOT out there!  So much so, it could be very overwhelming.  All of this is to simply say, I get it. Been there. My recommendation to you, if you're new to the field, is to not overwhelm yourself.  Being overwhelmed is self-inflicted; don't do that to yourself.  Yes, there is a lot to learn, but you don't have to know all of it now.  And you're never going to know all of it.  No one does.

Pick an area of interest, and learn about it.  At the very least, you may decide, "meh, this isn't for me." And you know what?  That's great.  That's okay. That's freakin' awesome!  Don't do something you don't enjoy.  That's the great thing about this industry - there are so many things out there, like hard, technical skills, soft skills, etc., that there's something for everyone. You can be the best technical writer, the best policy analyst, or the best malware reverse engineer you can be.  You can be a great pen tester, or you can opt for the 'blue' side, in DFIR.  Within each of those broad areas, you can further specialize.  But the point is, don't try to boil the ocean.

Be a good generalist, but also specialize in something.  Become good at something.  Then become good at something else.  But also understand, you don't have to be great at everything.  Understand that, deep in your bones.  Know it.  Because you're going to run into "gatekeepers" in this field (just as you will in any other field) who are going to tell you that in order to be a success, you have to model yourself after them.  Not true.  In fact, some of those folks who demand that you be great at everything have some pretty major holes in their own armor.

One of the things I've done is look to an area that doesn’t already have a great deal of attention.  For example, when I was a kid, I played soccer. At the time, everyone wanted to be a forward...forwards scored goals and got all the glory.  No one wanted to be a defender, a fullback, the last line of defense before the goal keeper.  But instead of competing for a forward slot, I ended up getting pretty good at being a defender. Jump forward 20-odd years, and I was working in a shop with half a dozen folks who all swore that Linux was the only true operating system in existence, and no one was taking a good hard look at Windows from the perspective of performing vulnerability assessments.  And yet, all of our customers had infrastructures that consisted of mostly Windows systems.  So, I started digging into Windows systems, with the goal of understanding how to not only determine the point-in-time state of the system, but also how to look across all systems and determine the state of processes and procedures for that environment.  Along the way, I ran across this fascinating thing called the "Registry", and the more I dug into it, the more I learned that I didn't know.  Further, the more I dug into the Registry, the more I learned that few, if any, other analysts were really interested in the Registry.  In those early days, when I would take a break from learning about the Registry and talk to others, I'd learn that most acknowledged that it existed, and some even knew something about it.

Just because I've written two books on the Windows Registry doesn't make me an "expert". Nor has it led to me being sought out, nor recruited, as an expert.  But you know what?  I enjoy digging into the Registry, seeing what's there, and then looking to see how user and adversary behaviors are reflected in the Registry.

A great way to see how far you've come in a learning something is to put together a presentation, and teach what you know to others.  This can be as simply as a "lunch-and-learn" brown bag training session for your team, even done remotely.  This can really help you put your thoughts in order, and as you're developing the presentation, maybe even see gaps in your knowledge and understanding.  Start with what academics call a "literature search"...see what else is already out there.  If you don't have something ground-breaking or earth-shattering, don't worry about it...we all don't know everything, and it's more than likely that most of what you're going to present is going to be beneficial to others, anyway.

Speaking of presenting, Brett Shavers recently published a really good article covering the three most common fears folks encounter when speaking in DFIR.  Not only does my own experience show that Brett's right, but by putting a name to the fears, we call them out of the shadows and into the light where we can address and overcome them.

The Most Important Thing
The most important thing in the industry is you.  Self-care is critically important in this industry.  There will be a good deal of stress placed on you; some, or most of it may be self-inflicted.  You need to ensure that your physical, emotional/mental, and spiritual needs are met.

As an incident responder and consultant, there were times when I was flying out to some remote location. I didn't always have control of when that would occur; many times, a customer would call for immediate response on the West Coast after I'd already put in a full day's work.  This meant that I would get rest as I needed it, stay hydrated, eat healthy (something you can't always do on the road), and be sure to take vitamin supplements, as needed.  To this day, I like to keep Airborne on hand, and will be more focused on taking it when I know I'm traveling.

From an emotional perspective, put the time in to learn about and understand yourself.  Understand what works for you and what doesn't.

I've taken the Myers-Briggs Type Indicator test a lot over the years.  It started when I was on active duty, and the whole time I've been a very strong ISTJ, and I haven't really deviated from that over the years.  What does that mean?  Well, as an "introvert", I recognize how engaging with crowds or large groups of people affect me.  I can go to a conference, engage and participate, but at some point, I'm going to need some "me time".  This can be as simple as getting away for a few minutes, taking a nap, or getting some exercise.  I know that when I do this, I can return refreshed and ready to engage again, rather than be exhausted, sullen, and moody.  People recognize when everything about your body languages says, "I just want to get out of here".  When I've been to multi-day user conferences, try to plan for down time, so I can recharge.

A great book to read, for anyone, is Chapman's The Five Love Languages.  Reading this book and thoughtfully applying the content to ourselves is a great way to begin, or continue, developing self-awareness.  This book applies to relationships, and not just relationships with a spouse or better half, but any relationship.  You can apply what you learn from this book to your kids, family members, friends, and it will even apply when you're doing incident response.  For example, different customers will respond in different ways; some will get a sense of your credibility because they see you doing things, but others may react better to direct, concise verbal reports, or to you just spending the time to listen to them.

Further develop self-awareness by studying emotional intelligence.  Understand your "triggers", learn to recognize those internal forces that cause you to react or feel a certain way, and do this before responding.  Develop an understanding of why you react the way you do, before you respond.  If someone says something to you, verbally, via email or Twitter, etc., what is it that causes you to react the way you do?  Is your reaction negative or positive?  Remember, not everyone has the same perspective you do, and someone who's responding to you, especially online, is going to be in a place that you can't see and may not understand.  So, look at your reactions before responding.

Develop A Network
No one of us knows everything.  I know, I know...that's not easy to hear.  It's easy for us to sit back and assume that someone else knows everything, and then use that as an excuse to not engage with them.  This means that we miss an opportunity to develop our network.  The reason for this is that there is no one person that knows everything or has seen everything in this industry, and sometimes, just seeing a different perspective, even seeing the same thing but from a different point of view, can be very enlightening.

Developing a network goes far beyond clicking "Like", or "RT". Or even beyond clicking both "Like" and "RT".  It goes well beyond just sending someone a connection request, and then doing absolutely nothing beyond that.  Developing a meaningful network requires effort, not only in reaching out to others, but also responding when others reach out.

Stories abound of people not getting jobs through the traditional application submission process, but finding a great job via their network.  This happens because those people put in the effort to build their network.  They reached out to others, and responded when others reached out.

When you are engaged in developing a meaningful network, whether online or in-person/IRL, there are some of things you can do to make things work for you.

First, Be Present.  Nothing says you're simply not interested in the other person more than being distracted and somewhere else mentally. If you're going to attend a social function, a conference presentation or a meeting, and if you absolutely cannot be away from your phone and your email, don't go.  Reschedule.  Send someone else.

What does not being present look like?  Someone goes to a conference, one for which all of the speakers had to send in their slide decks for inclusion on the conference DVD or at the conference web site.  I've been to conferences where the schedule and all of the presentations were available on a smartphone app, so any attendee could access them at any time, and didn't have to be sure to download them prior to the conference.  Then at the beginning of the presentation, the speaker states, "...these slides are available on the conference ...".  However, by the end of the presentation, someone still asks if and where the slides will be available.

USMC Gen. John Allen has been in the news recently, and I associated with him back when he was a Major, and we were both stationed at The Basic School (he commanded the Infantry Officers Course).  One of the things he'd have his instructors do is ask leading questions before a class, and if the student officers were not "present", they would reschedule the class for a less convenient time.

Being Present leads to Ask Good Questions.  If you're read a blog post, an article, or just attended a conference presentation or webinar, be sure to ask questions relevant to the topic.  If someone puts forth the effort to develop a conference presentation or article about something they did, maybe it's best to leave the "...did you also do these other things..." questions for another time, or medium.  Don't subvert or abscond with the context, using it as an opportunity for your own agenda.  If you have a question about something ancillary to the topic, be sure to ask, but do so in a manner and at a time when doing so doesn't derail the conversation.

Learn to Communicate, in both written and verbal form.  None of us are born with the innate ability to clearly and concisely communicate, it's something we learn over time, through experience and with feedback.  I have had experience writing, in various forms (reports, performance reviews, etc.), throughout my career, and I still had to work through understanding my boss's preferred writing style...what they preferred to see with respect to format and content in reports...at various jobs.  Very few of us are just inherently good communicators, and most of us need to work at it.  A little bit of effort in this area will go a long way.

Think about it.  Say you're a DFIR analyst or technical threat hunter.  Now, you have to clearly and concisely communicate your findings and their impact to a customer, someone who's not as technical as you are, and someone who has a different perspective and an entirely different set of concerns than you.  This is also someone who's looking to you, as the 'expert', to communicate with them in a means that they can understand.  This means that you can't communicate to them as you would your peers.

Seek Feedback.  I found this to be highly effective when working high-stress IR engagements (I know what you're thinking, "...aren't they all??").  By finding the appropriate time to ask my point of contact, "how're we doing?" or "how're things going at this point?", I'd get valuable information about their expectations and perspective.  From that feedback, I could then compartmentalize those things that I needed to address immediately, and those things I needed push up to my manager immediately.

This isn't limited to customers.  As an analyst, seek feedback from your peers and your manager, and if you're a manager, seek feedback from your subordinates.  Create a culture where it's easy to do this, without fear that it will be "used against" someone, but will instead be used to make everyone better analysts, better teammates, and stronger peers.

When it comes to your network, and making it stronger, Stop Assuming. What is one of the assumptions I hear from people?  "I assumed you were too busy to answer my email."  Nothing is further from the truth.  I know that some people where "busy" like a badge of honor, so I get it.  But that's not me.  Yes, I have reached out to people, via what I thought was their preferred medium (i.e., email, Twitter, etc.) and not received so much as an acknowledgement.  But so what?  I have no idea what's going on in their life.  The simple fact is that I've always tried to respond in a timely manner, even if it's just a "hey, I got your email and I'll take the time here soon to give it the attention it deserves".  Don't let the assumption that "...they're too busy..." be your self-inflicted excuse for not asking someone a question.

There are other assumptions I hear, but the point is, you can assume something and limit yourself through a self-imposed obstacle, or you can just ask.

Finally
The last thing is to keep the "3 Foot World" principle in mind.  You can only directly affect those things within three feet of you, within arm's reach.  I got this principle from reading a first-person account by a member of SEAL Team 6, as he was recounting going through specialized training in rock climbing.  The thing is, it applies to life equally well.  We have to understand that the only thing that we can control is ourselves...how we respond to things...and the only things that we can directly impact are those things within our 3 Foot World.

What does this mean?  Well, when I was doing incident response on a regular basis, I realized early on that these events are stressful for everyone involved.  However, I cannot control when an adversary is going to suddenly become visible to a customer, and I cannot control how the customer is going to respond.  However, what I could control was my own "3 Foot World", and I did that by developing a process to be prepared for those calls for immediate response that invariably came in at 10:45pm on a Friday.

Before GPS was readily available, I'd get the address of where I was going in relation to the closest airport, and print out 3 different levels or "views", to have with me.  That way, I knew how to get where I was going once I was on the ground.  Once GPS devices got to a point where they were affordable, one of those went into my carry-on bag.  Copies of all imaging documentation, along with any other important templates, went into both my carry-on bag and my checked Pelican case.  I had a hard copy of all important phone numbers (my boss, the customer, etc.), in case all I was left with was a credit card, or just a quarter, to make a phone call (i.e., "my cell phone died" was no excuse).

Everything that went into my carry-on bag went into the same place.  The same was true for my Pelican case...everything went into the same place, and got repacked in the same place when the engagement was complete.  Tableau imagers, laptops, cables, documentation...everything went into the same place.  Also, when there was time, priority was placed on ensuring that software was updated between engagements.  Did I have the latest copies of commercial tools, were my processes up-to-date?

The purpose of all of this was to provide the best service I could to a customer, given that I'm going to be engaging with them during a really stressful time, very likely when they were exhausted, as well as when emotions were running high.  Showing up on-time and prepared may seem like a little thing, but when you're meeting with someone for the first time and they've been pulling 20+ hr days for 10 consecutive days, and the first thing out of your mouth is, "Sorry I'm late..." or "...I forgot this very important item that I need to do my job..."...needless to say, that does not make for a good first impression.

Recognize the "3 Foot World" principle, and apply it.

EvtxECmd

Eric Zimmerman recently released EvtxECmd, a nifty Windows Event Log file parser that bypasses the Windows API.  There are a lot of advantages to a tool such as this; specifically, by bypassing the API, it doesn't succumb to the 'hiccups' that may occur as a result of files that weren't closed properly, or for some other reason, isn't formatted in a manner the API agrees with.  This is something I've seen with LogParser, as it uses the Windows API, and will fail to parse a file if there's something 'amiss'.

Using data from the Lone Wolf Scenario, I extracted some (not all) of the Windows Event Log files from the image, and used the following command line to run EvtxECmd against this subset of data:

evtxecmd -d F:\lonewolf\data\evtx --csv F:\lonewolf\data\evtx --csvf output.csv

Not only was the output file generated, but a lot of data flew by in the command prompt while the command was processing.  I thought that this might be useful information, so I deleted the output file and re-ran the command:

evtxecmd -d F:\lonewolf\data\evtx --csv F:\lonewolf\data\evtx --csvf output.csv > F:\lonewolf\data\evtx\evtxecmd_trace.txt

Once the command prompt returned, I had the output file, as well as the 'trace' file that contained all of the information provided via the prompt.  A good deal of it was very useful, such as metrics based on the event IDs (albeit without the event sources, or some other unique identifier) and the count of said event IDs found in that log file.  This can be very useful information, and as such, I'd recommend collecting it as part of your investigative process, and keeping it alongside your case notes.

As to the output of the command, the output file contained 31,956 entries; by comparison, Logparser (run via wevtx.bat) threw an error about not being able to open a file (it didn't specify which one), and produced output with 24,770 entries. Clearly, incorporating EvtxECmd into your investigative process will provide a more complete view of the available data, from a total number of events perspective.

However, let's look at some differences in the actual output.  I've always been fascinated by the use of BITS for downloading (and uploading) files.  As there are a number of BITS Client events available, let's look at a simple event, such as event ID 3.

The output from wevtx.bat, using Logparser, looks like this (i.e., TLN format):

1522194038|EVTX|DESKTOP-PM6C56D||Microsoft-Windows-Bits-Client/3;C:\Users\jcloudy\AppData\Local\Temp\{33340A58-DC7C-4FBB-82A9-24EFA8F8C38D}-gsync64.msi,{50A0E739-31CE-4B89-8972-DE76CC505D31},DESKTOP-PM6C56D\jcloudy,C:\Program Files (x86)\Google\Update\GoogleUpdate.exe,9004

The output directly from EvtxECmd for a similar event record looks like this:

279,279,2018-03-30 21:09:16.6870673,3,4,Microsoft-Windows-Bits-Client,Microsoft-Windows-Bits-Client/Operational,3636,11240,DESKTOP-PM6C56D,S-1-5-18,,,,,,,,,,,F:\lonewolf\data\evtx\Microsoft-Windows-Bits-Client%4Operational.evtx

In the case of the EvtxECmd output, there seems to be some important information missing. Talking to Eric about this, he said that in order to get the additional details (i.e., strings, event description) in the CSV output, you need to have a map file for the event.

So, there you go.  Once the appropriate map files are in place and the event description available as part of the output, given the header of the output file, it will be relatively easy to write a script that will translate the output of the tool into something easily incorporated directly into a timeline, for direct inclusion into an analysis process.

For your analysis process, Eric includes map files (read Eric's info for more detail...)...when I ran the tool, there were 52 map files available.  Eric provides a description of how to create your own map files.

A note on using Eric's CLI tools: whenever I install a system, one of my first configuration steps is to modify the command prompt to a white background with black letters.  This makes things much easier for screen captures, particularly for books and presentations.  When running Eric's CLI tools for the first time, I'll get a lot of blank lines in the output, and highlighting or selecting the contents of the screen does not reveal the underlying text.  I reached to Eric and he said that I needed to get the nlog.config file from his site, and include it in the directory with each of the command line tools.  I simply created a folder for Eric's tools, and put one copy of the file alongside all of the other tools.

Resources
Link to EvtxECmd Maps

What's New...

Magnet Forensics Free Tools
The folks over at Magnet Forensics have several free tools available, which were discussed recently on the 13Cubed YouTube channel.

Analysis
Okay, so parsers abound (more on that later), but what then? Parsing is great, but that's just the first step toward analysis, and the true value of a tool, regardless of where it comes from, is how it integrates into your analysis process.  Parsing is not analysis.

On a bit of a side note on that topic, IWS was released last fall, and I'm still somewhat curious to see how it's received by the community. In the book, I exposed my analysis process, in a manner that anyone can follow along with; with the exception of the first image (which seems to be no longer accessible), anyone can download the images, and perform their own analysis.  This is a complete departure from my previous work; in all of my previous books, I'd followed a pretty standard formula...here's an artifact, here's how to parse it, here's what it can tell you...but like other works, I'd pretty much left it to the reader to figure out how to stitch everything together into a cohesive investigation.  IWS is my first real shot at doing that, going beyond just throwing up my findings into a blog post.  Yes, I've been told, "...it's good...", and "...I like it...", but like a brewer who's stepped outside their comfort zone and tried something radically different from their previous approach, I'm really curious to better understand what readers really think about the content of the book, how it impacts them, and

JumpList AppID
Not long ago, I saw a question about an Automatic JumpList application ID; the OP was asking which application the AppID referred to.  I did a quick Google search and found no reference to that specific AppID, but it did get me thinking...how can someone go about determining the AppID of a JumpList, when said AppID is not publicly listed?

I came up with two means for doing so, and in hindsight, they are not mutually exclusive; that is, one supports the other.

The first method would be to parse the JumpList and get a list of files that it points to; you can get this information from both the individual LNK streams within the JumpList file, as well as the DestList stream.  From there, you could then check the Registry for file associations; that is, which application is associated with the listed file's extensions.

The second method would be to create a timeline of system activity, and include the JumpList DestList stream as a data source.  With additional information, such as UserAssist and BAM entries, RecentDocs values, Prefetch metadata, etc., you should be able to 'see' applications that were launched prior to at least some of the files in the JumpList DestList stream being accessed.

Presentations
I've got a couple of upcoming presentations, the first one being at RVASec, coming up later this month. I've submitted to OSDFCon this year, as well, but that's in the fall.

A friend asked me to provide a presentation to her forensics class, which I did recently, via Zoom.  I resurrected a presentation on Registry analysis, which I thought was appropriate given the audience, and it seemed to pretty well-received.  If anything, I hope that seeds were planted.

LNK Files In The Wild

The FireEye folks recently shared a fascinating article regarding a spear-phishing campaign that involved the use of 'weaponized' LNK files, two of which were of particular interest:

1. SPEC-10T-MK2-000-ISS-4.10-09-2018-STANDARD.pdf.lnk
MD5: ec0fb9d17ec77ad05f9a69879327e2f9

2. From the Related Samples section is another LNK file with a filename that includes the Ukranian word for "Conclusion"
MD5: fe198e90813c5ee1cfd95edce5241e25

It turns out there are some similarities in the metadata of the LNK files, but also some odd differences.

Similarities:
Basepath, shellitemIDlist: C:\Windows\System32\mshta.exe
Description: "Type: Text Document"
Iconfilename: ".\128_2_21.docx"
Commandline: Very similar, both point to same domain, although the command line in LNK 1 is base64 encoded, and in LNK 2, it isn't
PropertyStoreDataBlock: both contain the same SID, S-1-5-21-871675894-2481818095-1561791058-1002

Differences:
Volume SN: Volume serial numbers are different both systems
TrackerDataBlock: Both LNK files have different TrackerDataBlocks, including the machineID field.

In the past, similarities in LNK file metadata (machineID, volume serial number, MAC address) have been attributed to a single VM being shared.  So, the question becomes, how do different LNK files include the same user SID, but different volume serial numbers, NetBIOS machine names, and MAC addresses?

The MAC address artifact, I get.  I can also see how the iconfilename might be the same; personally, I'm a fan of re-using things that work.  The description field is entirely optional, and the fact that they're the same between LNK files is interesting.  In and of themselves, the different values in the TrackerDataBlock (machine ID, MAC address) are not unusual, but given that the SIDs are the same, that is odd.  Could it be the result of something like this?  If so, that's pretty darned specific.

Thoughts?

Registry Transaction Logs, pt II

My previous blog post on this topic was an initial look into what happens (i.e., changes, what 'new' data is available, etc.) when you merge Registry transaction logs into a hive.  This started out with me just looking at what tools were available for doing so, and then expanded a bit into, "oh, let's see what changes were made in the hive file...".

In this post, I wanted to provide a bit more information and clarification around what I did and what I found, so that others can more clearly see the process, and hopefully, the value of pursuing this sort of testing and research.

Clarification
My initial testing led to some very interesting findings, one of which was stated as the following:

The del.pl plugin produced some interesting results.  When I ran it against the original System hive, it pulled out a number of deleted keys and values; however, running it against the 'new' (i.e., merged) hive, I got nothing.  Not one deleted key, not one deleted value.

Now, the assumption here might be that there are no deleted keys and values after the transaction logs have been merged into the hive, and that would be incorrect.  The reason that the tool displayed no findings on the second run (and thanks to Maxim for providing insight into this...) is that the plugin only checks the beginning of a free cell for indications of a deleted key or value node; it doesn't traverse and check the entire cell.  This is why we have tool testing and verification, and what leads to those of us who write and use such tools to update them.

So, for the sake of clarity, merging the transaction logs into a hive file does not remove all unallocated space and deleted cells. That being said, there is significant value in running tools that check for deleted cells across both the original and the merged hives.

Tools
For testing, I opted for using the LoneWolf scenario image, as it is readily available.  Any hives and their corresponding transaction logs can be used, but going with a publicly available image allows for clarity and simplicity in discussions.  I opened the image in FTK Imager, and extracted System hive from the system32\config folder, along with the System.log1 and System.log2 transaction log files.

As to merging transaction logs into hives, I tweeted a question regarding tools used to merge hives and transaction logs. I got a response from Maxim, stating "yarp + registryFlush.py".  Once I got everything set up and running, this process ran as advertised.  I passed the necessary arguments to the script, and ended up with four files in the folder:

03/27/2018  05:45 PM        12,845,056 SYSTEM
09/29/2017  04:45 AM         3,163,136 SYSTEM.LOG1
09/29/2017  04:45 AM         3,211,264 SYSTEM.LOG2
04/08/2019  04:04 PM        12,845,056 system_2019-04-08@160420

At this point, I have the 'dirty' hive and transaction logs extracted from the image, as well as the 'merged' hive file.  Note that the file system reports the 'dirty' and 'merged' hives as being the same size.

Deleted Keys/Values
I mentioned checking for deleted keys and values at the beginning of this post; Maxim provided this advice regarding the use of the "yarp-print" tool as the more accurate approach to recovering deleted keys and values.

Specifically, if you're using yarp on Windows, start by opening a command prompt, navigating to the folder where the tools are located, and type:

set PYTHONIOENCODING=utf-8

Then, to parse deleted keys/values from the 'dirty' hive, you can use the following command:

yarp-print --deleted --no-recovery SYSTEM

In this case, you would used the --no-recovery switch as the tool will automatically attempt to discover the transaction log files.

In order to parse the deleted keys and values, incorporating the transaction logs into the process, you'd use the following command line, if you extracted the transaction logs into the same folder as the hive file:

yarp-print --deleted SYSTEM

Again, the yarp tools will attempt to discover the transaction logs for you, and incorporate them into the parsing.  This also means that you can use the yarp-print tool to extract deleted keys and values from the merged hive, using the following command:

yarp-print --deleted system_2019-04-08@160420

In this case, you don't have to use the --no-recovery switch, as the tool won't find transaction logs associated with the merged hive.

RegRipper
As I mentioned in my previous post, one of the interesting aspects of this testing was the differences in output from various RegRipper plugins when run against the 'dirty' and 'merged' hives.

The output of the mountdev.pl plugin, when run against the 'merged' hive, included an additional DosDevice entry:

\DosDevices\F:
  Drive Signature =  76 d4 59 81

The output of the bam.pl plugin, when run against the 'merged' hive, included two additional entries for the user with RID 1001:

Fri Apr  6 12:27:06 2018 - \Device\HarddiskVolume4\Program Files (x86)\Microsoft Office\root\Office16\EXCEL.EXE
Fri Apr  6 12:41:21 2018 - \Device\HarddiskVolume6\Programs\Imager_Lite_3.1.1\FTK Imager.exe

The same output also included an entry for the Local System account that was not in the 'dirty' hive:

S-1-5-18
  Fri Apr  6 12:40:38 2018 - \Device\HarddiskVolume4\Windows\System32\csrss.exe

Take-Aways
Just with this initial testing, using just this one hive, we can begin to see the value of making use of the hive transaction logs.  The System hive used in this case was not from a high-use system; that is to say that it was from a forensic challenge scenario system, and not a system used in a corporate environment.  Regardless, this limited testing did allow us to see that there is considerable value in incorporating the transaction logs in our Registry parsing process.

Other images are available online which may be used to further this testing.  For example, the Mystery Hacked System image includes activity within the user profiles, and as such, may prove to be interesting and provide even more support for this process.

Finally, after merging the transaction logs, I ran some basic diff utilities against the 'dirty' and 'merged' hives, and noted that there were a number of entries that appeared in the 'merged' hive that were not visible in the 'dirty' hive.  A method for narrowing this down a bit might be to run RegRipper profiles against both, and then run text-based diff utilities against the results of each of the profile runs.

Next Steps
My next steps are to examine additional tools (specifically, Eric Zimmerman's Registry Explorer and RECmd tools) that can be used in this process, and leveraged to take advantage of the additional data within Registry transaction logs.

References
Maxim - Exploring intermediate states of a registry hive
FireEye - Digging up the past

Other Tools
Regipy - alternative tool for merging transaction logs (note: I'm working with the author...)
RegRippy - RegRipper alternative, written in Python3

Latest Testing: The Windows Registry, pt I

I've always been interested in and fascinated with the Windows Registry, in large part due to the fact that early in my DFIR career few really seemed to have a good grasp on, or interest in, just how central it is to the Windows operating system.  By extension, the grasp, for the community at large, as to the analysis value of the Registry was underestimated.  We've seen changes to this attitude over the years, and as the migration to incorporating the Windows Registry into analysis has progressed, so has the development of techniques for deriving even more analysis value from the Registry.

Interest in the Registry as a source of data for digital analysis and incident response has waxed and waned over the years. In the late '90s while I was performing vulnerability assessments, there was considerable utility in querying the Registry from live systems in order to determine the state and attack surface of those systems.  We were looking for (and finding) active modems in systems, as well as extracting information about software versions, etc.  To a large extent, this remains true today; there is a great deal of data available in the Registry to assist in developing an understanding of not only the state of the system at a given time, but also activity that occurred on the system.

In 2008, Jolanta Thomassen shared her dissertation regarding parsing Windows Registry hive file unallocated space; that is, retrieving deleted keys and values from unallocated space within the hive file itself.  She also released regslack.exe, a command line tool for extracting deleted keys and values from hive files.  Other tools have followed suit, providing similar functionality. Eventually, RegRipper included this functionality, as well.

In the past couple of years, attention has turned to Registry transaction logs, and incorporating data from those logs directly into hive files in order to achieve a more comprehensive and perhaps 'correct' view of the hive contents.  As such, I wanted to determine what tools were available to merge transaction logs into a hive file, and from there, begin looking at the effect of the merge operation.

I installed Python 3.7 on a Windows 10 system.  I opted for Python 3.7, as it is required for a tool I'm planning to test, Regipy.  I installed yarp on that system, as well.  This is the system I'm using as the platform for merging hives with their transaction logs.

I began testing by using yarp + registryFlush.py (thanks to Maxim) to merge the transaction logs (hive.log1, hive.log2) into a hive file, using hives from the LoneWolf scenario due in part to their availability.  Once I had successfully merged the transaction logs into the System hive, creating a 'new' System hive file, I used registry-diff.py and regdiff.pl to document the differences between the original and 'new' hives.  As an example of differences between the two hives, while they were reported by the file system to be the same size, regdiff.pl found 2561 differences between the original and 'new' hives, many of which pertained to USB devices.

I should note here that this is a very interesting finding.  Several years ago, I ran into a situation where I was comparing the System hive from a system to it's 'companion' in the RegBack folder (clearly, this goes back to when the hives in the config folder were being actively backed up).  In that case, I found 9 USB devices listed in the System hive, and 13 devices listed in the backed up hive.  I did a text search across both folders for one of the device names (one that was unique), and found an entry in one of the .log files, but at the time, there were no tools available for merging the transaction logs into the hive.

I then moved on to looking at differences in the hives via RegRipper.  Again, for this initial set of testing, I was focusing on the System hive.  As the AppCompatCache (or ShimCache) data is written to the System hive at shutdown, I did not expect to see significant differences between the two hives, and that expectation was borne out by running the appropriate plugin against both hives.  However, the BAM and Mounted Devices plugins proved to be a bit more interesting.  For example, the output of the mountdev.pl plugin run against the 'new' hive contained a drive signature for an F:\ volume that did not exist in the original hive.  The bam.pl plugin showed two additional entries for the user with RID 1001 when run against the 'new' hive.  Also, there was an entry for the Local Service account in the 'new' hive (again, via the bam.pl plugin) that was not in the original hive.

The del.pl plugin produced some interesting results.  When I ran it against the original System hive, it pulled out a number of deleted keys and values; however, running it against the 'new' (i.e., merged) hive, I got nothing.  Not one deleted key, not one deleted value.

So, what does all this mean?

I started this out wanting to simply see what tools and processes could be used to merge transaction logs into their hive file.  I posted a tweet to that effect, and Maxim was the first (and only) person to respond (to that query).  I do have additional testing to do, not just with this script, but with other tools that are available, as well.  Again, what I'm looking at here is simply how to go about merging the transaction logs into a hive, and if successful, looking to see differences between the two in order to demonstrate the value of taking these steps.

Something to keep in mind is that Windows systems no longer appear to be populating (by default) the backup copies of the Registry hives within the config/RegBack folder.  As such, merging transaction logs into the hive files prior to any parsing and analysis processes would seem to be a pretty valuable approach, if not simply provide more complete information. From that point, it's a matter of conducting analysis. 

As far as a process goes, you'd likely want to either extract the appropriate files, or mount the image with the appropriate tool such that you could access the necessary directories.  From there, you'd want to keep the original hive, and create a new version of the hive by merging the transaction logs.  The new hive would ideally give you a more complete view of the hive, but the original hive would provide you with historical information, particularly regarding deleted content.

So, more to come...

Resources
I recently became aware of RegRippy, a Python-based alternative to RegRipper.

A Look Back...

I was chatting with someone recently with whom I'd crossed paths a bit more than 21 years ago, and throughout the time we chatted, I had this sense of nostalgia. What that led me to was the thought that when you've been in and around any industry for a while, it's interesting to take a step back and reflect on your path.

One example of nostalgia and looking back that comes about pretty regularly is when I meet former Marines.  I've met many who were anywhere between toddlers and elementary school when I left active duty, and when we talk about what we did, I have to remember that my MOS (military occupational specialty) no longer exists.  I was a Communications Officer, 2502, and the 25xx occfield is something a lot of current and former Marines have never heard of. So, nostalgia.

So, how does this relate to the cyberz? I first read The Cuckoo's Egg years ago, and thought, wow, what must it be like for Clifford and others involved to look back on what they did and the decisions they made?  What was it like to revisit the events of that time with someone else who was there, reminiscing with, "...hey, do you remember when...?"

When I started grad school in June 1994, I walked by Gary Kildall's office for about 4 months before he passed.  I never met the guy, and to be honest, would not have known who he was; I didn't find out until several years later.  At the time, I was use MS-DOS and Windows 3.1, and had transitioned to Windows 3.11 for Workgroups just prior to heading west.  I had never heard of CP/M, nor did I know much about operating systems at the time. 

While I was in grad school, OS/2 was a thing.  I went to Frye's Electronics in Sunnyvale to purchase a copy of OS/2 2.1, in part to install it on my desktop computer (with a 486DX microprocessor), but also to get the $15 off coupon sticker to apply to the purchase of OS/2 Warp 3.0.  I'd had to install a second hard drive in the computer, in part due to the fact that drives were so small back then. 

To get a sense of perspective of cost, I dropped $500 to upgrade to 16 MB (YES, with an "M") of RAM.  When you installed the second hard drive (the ribbon cables only had two connectors), you had to be sure to set the jumpers correctly.

As part of my master's thesis, I wrote an SNMP polling utility in Java.  This was just for the data collection phase of my thesis work; this was preceded by setting up a lab environment, using Windows 95 and Windows NT 3.51 servers, with two different network media (10-Base2, 10-BaseT) connected across two Cisco 2514 routers.  One of the routers was connected to the campus area network (CAN) via a 10-Base5 vampire tap.  I used simple video teleconferencing software to generate traffic across the network, and I used the SNMP polling application to collect traffic volume information over time.  Once volumes of data had been collected, I did all of the statistical processing and image display via MatLab.  To generate the traffic, I'd sit in front of one of the video cameras eating my lunch, and I'd sit in sight of the other camera.  I'd wave my arm to generate frame updates from the second camera.

As an aside, the knowledge I developed of SNMP would serve me quite well, well after I left grad school and the military.  Not only could I make recommendations to a network operations team regarding security (i.e., don't allow SNMP or even just UDP through the firewall, etc.) based on that knowledge, but I could also use what I had learned to develop information about systems during pen testing.  Yes, you'd be surprised what was accessible from the Internet back then (SNMP, NetBIOS), and even later.

All of the main terminals in my graduate program were SparcStations running Solaris (NetScape was the browser we used).  I'd used TRS-80s in high school (programming PASCAL) and college (programming BASIC), and my family's first home computer was a Timex-Sinclair 1000; the second was an Epson QX-10.  During that time (early '80s) I had also taken a course in BASIC programming on the Mac IIe.  Somewhere along the line, a friend of mine had a Commodore 64, but I wasn't into playing computer games so I didn't spend much time with it.  I never did touch an Amiga, but I did take two courses in grad school that involved using assembly language to program the Motorola 68000 microprocessor.

I was in grad school when SATAN was released (circa  1995).  Shortly after it became available, I transitioned to the role of being the student rep from my academic department to the IT board.  I sat through more than a few meetings where the IT admins from across campus argued about running the scanner on each other's networks.  I never actually ran the tool; I was afraid to even download it.  This was due to the fact that I'd downloaded a copy of a file called "crack.c", in order to learn a bit more about C programming (for a course I was taking at the time).  I got in "trouble" with the senior sysadmin for the department because I had the file on my system.  I argued that I had never compiled it (part of the course was the compilation process), never created an object file, never linked it, etc.  None of that mattered to her.  Things went really sideways when she'd claimed that I had violated THE security policy; knowing that I'd never signed such a thing, I asked to see the security policy. That's when she turned red and stormed off.  Even though the two other admins were on my side, I was in the doghouse with the senior sysadmin. The fact was that it was another year before a new Admiral took of the school as superintendent and there was an actual written security policy.  Even what that policy was available, downloading crack.c would not have been a violation. 

As my active duty time ended and I was processing out of the military, I was attached to the Marine Detachment at the Army's Defense Language Institute (DLI). My role at the time was to connect the computer systems in the detachment to the Army's CAN, which was token ring. Around that time, the Commandant of the Marine Corps (Chuck Krulak) had stated that Marines were authorized to play "Marine DOOM", and the detachment had purchased 6 Gateway computer systems for that purpose.  These systems were set up on a round credenza, connected via a 10-Base2 network, running IPX.  At one point, a SSgt joined the unit and decided to make the room his office.  To make more room, he had the Marines split the credenza in half and place the flat parts against opposite walls, with 3 stations on either side of the room.  To do so, the computers needed to be disconnected.  Once everything was in place, the computers were reconnected, and attempts were made to run the game, all of which failed. As the SSgt approached me for assistance, I didn't realize until much later in life that this was my first consulting gig.  The SSgt informed me that the computer network had been reassembled EXACTLY as its previous state.  I took a look at the system at the end of the network, and realized that the RS-232 connector had been attached directly to the NIC; looking around, I found the T connector and terminator sitting under the keyboard.  No one saw me reconnect everything, but I told the SSgt to try again, and the network sprung to life.  Within minutes, the Marines were back to playing the game. 

In one of my first jobs out of the military, I was doing assessment work.  During that time, I spent time in one of the Twin Towers in New York City, doing war dialing work.  Our tools of choice were THCScan and ToneLoc. It was pretty exciting for two of us to sit in a cubicle, with the sound turned way down on the laptop we were using, listening to the responses we were getting from remote systems.  Most of the time, the phone on the other end would be answered, and we'd hear "hello" come out of the speakers. It really got exciting when we could hear software dial a number, and a phone ring two cubicles down, and the person in that cubicle respond, their "hello" echoing in the speaker of the laptop.  When the software dialed the cubicle on either side of us, we threw our jackets over the laptop to ensure that the residents didn't hear us.  We got "caught" when the software dialed phones on opposite sides of the mainframe room; the mainframe admin wasn't happy about having to get up and walk across the room apparently, and he called the CIO to report the activity. 

I later worked at Trident Data Systems (TDS), where I was doing vulnerability assessments and some light pen testing work.  We used ISS's Internet Scanner for our vulnerability assessment work, and while I was there, I began developing a tool we called "NTCAT" to replace the use of ISS's tool.  We were getting a good bit of spurious findings from Internet Scanner, most notably with respect to the Windows "AutoAdminLogon" setting, and were learning more about what Internet Scanner was doing.  That is, what data it was collecting, and how it was making it's determinations.  And this is where we were running into issues, which we were addressing using this new tool.  When I wasn't doing assessment work or writing reports, I was connected to the lab, developing and testing NTCAT.  This is also where I really started to see the value in graphic representations of data, albeit in a very simple format (i.e., red for bad, green for good).  I also began to see, up close, the value of processing data in different ways; getting a quick SWAG while you're on-site, versus a deeper inspection of the data when you had time.  Taking it a step further, we were finding out new things and developing new tools to process the data, making things more useful and valuable to the analyst, and subsequently to the customer.

One of the things I pitched to my manager at the time was that once we collected all of this data from the customer, we had it.  We'd need to address it legally, through our contracts of course, but we could keep the actual data in a secure manner (encrypted and/or stored offline on a CD), and as we learned new things, run this new processing across the retained data.  It's interesting to look back on those discussions, and then look at what we do now with respect to MSS and EDR, particularly regarding data retention times.  I've seen some of the same questions and issues from back then in today's world; few EDR tools provide a retrospective look at what happened on a system prior to the installation of the agent or sensor, and as such, IR teams have to use other means to collect this historical data.  Things brings up questions of "what do you collect?", "how do you collect it?", as well as "how long can you keep the data?"  Times have changed, technology has changed, but we still see some of the same issues.

During my time with TDS, some members of our team were working a pretty big pen test, and had run up against an Internet-connected PBX.  They really wanted to get access to this PBX, and worked hard at doing so.  At one point, several members of the team went to the loading dock on the first floor of our building for a smoke break, and were talking about what they'd run into.  On the first floor of our building was an engineering firm, one that specialized (as it turns out) in that PBX. While our guys were out on their break, one of the engineers was just finishing up a break of his own when he overheard what they were discussing.  He walked over and offered them the 15 character password that was hard-coded into the PBX. 

In another job, I worked (indirectly) for a security director who'd appeared by name in the book TakeDown.  Several years later, while I was attending a conference in Seattle, I saw Kevin Mitnick.  I didn't talk to him...he was surrounded by a mob, and I don't do mobs. Also, I wasn't really sure what I'd say. 

As time passes, I may write some additional posts, looking back on the things I've seen, as well as folks I've engaged with.  We'll see...