Links and Updates

RegRipper Plugin
Not long ago, I read this blog post by Adapt Forward Cyber Security regarding an interesting persistence mechanism, and within 10 minutes, had RegRipper plugin written and tested against some existing data that I had available.

So why would I say this?  What's the point?  The point is that with something as simple as copy-paste, I extended the capabilities of the tool, and now have new functionality that will let me flag something that may be of interest, without having to memorize a checklist.  And as I pushed the new plugin out to the repository, everyone who downloads and uses the plugin now has that same capability, without having to have spent the time that the folks at Adapt Forward spent on this; through documentation and sharing, the DFIR community is able to extend the functionality of existing toolsets, as well as the reach of knowledge and experience.

Speaking of which, I was recently assisting with a case, and found some interesting artifacts in the Registry regarding LogMeIn logons; they didn't include the login source (there was more detail recovered from a Windows Event Log record), but they did include the user name and date/time.  This was the result of a creating a timeline that included Registry key LastWrite times, and led to investigating an unusual key/entry in the timeline.  I created a RegRipper plugin to extract the information (logmein.pl), and then created one to include the artifact in a timeline (logmein_tln.pl).  Shorty after creating them both, I pushed them up to Github.

Extending Tools, Extending Capabilities
Not long ago, I posted about parsing .pub files that were used to deliver malicious macros.  There didn't seem to be a great deal of interest from the community, but hey, what're you gonna do, right?  One comment that I did receive was, "yeah, so what...it's a limited infection vector."  You know what?  You're right, it is.  But the point of the post wasn't, "hey, look here's a new thing..."; it was "hey, look, here's an old thing that's back, and here's how, if you understand the details of the file structure, you can use that information to extend your threat intel, and possibly even your understanding of the actors using it."

And, oh, by the way, if you think that OLE is an old format, you're right...but if you think that it's not used any longer, you're way not right.  The OLE file format is used with Sticky Notes, as well as automatic Jump Lists.

Live Imaging
Mari had an excellent post recently in which she addressed live imaging of Mac systems.  As she pointed out in her post, there are times when live imaging is not only a good option, but the only option.

The same can also be true for Windows systems, and not just when encryption is involved.  There are times when the only way to get an image of a server is to do so using a live imaging process.

Something that needs to be taken into consideration during the live imaging of Windows systems is the state of various files and artifacts while the system is live and running.  For example, Windows Event Logs may be "open", and it's well known that the AppCompatCache data is written at system shutdown.

AmCache.hve
Not long ago, I commented regarding my experiences using the AmCache.hve file during investigations; in short, I had not had the same sort of experiences as those described by Eric Z.

That's changed.

Not long ago, I was examining some data from a point-of-sale breach investigation, and had noticed in the data that there were references to a number of tools that the adversary had used that were no longer available on the system.  I'd also found that the installed AV product wasn't writing detection events to the Application Event Log (as many such applications tend to do...), so I ran 'strings' across the quarantine index files, and was able to get the original path to the quarantined files, as well as what the AV product had alerted on.  In one instance, I found that a file had been identified by the AV product as "W32.Bundle.Toolbar"...okay, not terribly descriptive.

I parsed the AmCache.hve file (the system I was examining was a Windows 7 SP1 system), and searched the output for several of the file names I had from other sources (ShimCache, UserAssist, etc.), and lo and behold, I found a reference to the file mentioned above.  Okay, the AmCache entry had the same path, so I pushed the SHA-1 hash for the file up to VT, and the response identified the file as CCleaner.  This fit into the context of the examination, as we'd observed the adversary "cleaning up", using either native tools (living off the land), or using tools they'd brought with them.

Windows Event Log Analysis
Something I see over and over again (on Twitter, mostly, but also in other venues) is analysts referring to Windows Event Log records solely by their event ID, and not including the source.

Event IDs are not unique.  There are a number of event IDs out there that have different sources, and as such, have a completely different context with respect to your investigation.  Searching Google, it's easy to see (for example) that events with ID 4000 have multiple sources; DNS, SMTPSvc, Diagnostics-Networking, etc.  And that doesn't include non-MS applications...that's just what I found in a couple of seconds of searching.  So, searching across all event logs (or even just one event log file) for all events with a specific ID could result in data that has no relevance to the investigation, or even obscure the context of the investigation.

Okay...so what?  Who cares?  Well, something that I've found that really helps me out with an examination is to use eventmap.txt to "tag" events of interest ("interest", as in, "found to be interesting from previous exams") while creating a timeline.  One of the first things I'll do after opening the TLN file is to search for "[maldetect]" and "[alert]", and get a sense of what I'm working with (i.e., develop a bit of situational awareness).  This works out really well because I use the event source and ID in combination to identify records of interest.

As many of us still run across Windows XP and 2003 systems, this link provides a good explanation (and a graphic) of how wrapping of event records works in the Event Logs on those systems.