Thursday, May 28, 2015

Detecting Lateral Movement

Almost two years ago, I posted this article that addressed how to track lateral movement within an infrastructure.  At the time, I'd been using this information successfully during engagements, and I still use it today.

This morning, I saw this video from Rapid7, and I thought that Mike did a great job with the presentation.  Mike made some very good points during his presentation.  For example, "SMB" is native to a Windows infrastructure, and with the right credentials, an adversary can go just about anywhere they please.

There were some things missing in the presentation, some caveats that need to be mentioned; I do understand that they were likely left out for the sake of time.  However, they are important.  For example:

Security-Auditing/4698 events - Scheduled Task creation; under Advanced Security Audit Policy settings, for Object Access, you need to have Audit Other Object Access Events enabled for this event to appear in your Windows Event Logs.

Security-Auditing/4697 events - Service installation; similar to the previous events, systems are not configured to audit for system creation via the Security Event Log by default.

So, the take-away here is that in order for these (and other) events to be useful, what admins need to do is properly configure auditing on systems, as well as employ a SEIM with some sort of filtering capability.  Increasing auditing alone will not be useful...I've seen that time and time again when an incident is identified; auditing is ramped up suddenly, and the Security Event Logs start filling up and rolling over in a matter of a few hours, causing valuable information to be lost.  The best thing to do is to enable auditing that makes sense within your infrastructure ahead of time, employing the appropriate settings (what to audit, increasing the default size of the Windows Event Log files, etc.) before an incident occurs.

Also, consider the use of MS's Sysmon, sending the collected data to a SEIM (Splunk??).  Monitoring process creation (including the command line) is extremely valuable, and not just in incident response.  For IR, having the process creation information available (along with a means to monitor it in a timely manner) reduces IR engagements from days or weeks to hours or even minutes.  If setting up Sysmon, Splunk, and filters is too daunting a task, consider employing something like Carbon Black.

Thanks to Rapid7 for sharing the's some great information.

Description of Security Events in Windows 7/Windows Server 2008 R2

Tuesday, May 26, 2015

Links and Stuff

Registry Goodness
I recently wrote a RegRipper plugin, based on this KB article; on 26 May, I committed it to the plugin repository.  I had tweeted to ask the DFIR community if this information was relevant to their investigations, and there was not a great deal of response on the topic...although there was apparently some confusion.  I hope that folks take the time to try it, and I hope it's of some use to the DFIR community.  I don't often (scratch 15+ years of doing DFIR work, I've never...) need to determine the history of GPOs assigned to a system.

Speaking of RegRipper plugins, Dan posted recently about how he completed the SANS CEIC 2015 Challenge.  While he completed the challenge using Eric Zimmerman's Registry Explorer tool, he did state toward the end of the post that he could've used RegRipper to complete the challenge, as well.

From the recent CEIC Conference, you can see David Dym's slides for his Improving Windows External Device Investigations presentation.  I know that no matter how many times this subject is addressed and discussed, there will always be confusion as to what resources are available on Windows systems if you are conducting one of these investigations.  I think it's great that we've got others talking about this topic, particularly because there seems to be so much confusion in this area.  Cory Altheide and I published the initial research into this topic in 2005 (there's a link here), and as new versions of Windows have come out, more information has become available regarding not only which devices were connected to systems, but also which user may have accessed the device.

Speaking of the Registry, Eric Zimmerman recently released a command line tool for interacting with (including searching) a Registry hive file for specific items.  Be sure to get version 0.6 of the tool.  Eric's been doing a lot of work in creating freeware tools for accessing the Registry, so be sure to check out his other offerings.

Not related to Registry analysis, but TrendMicro recently had a blog post about what they seem to be presenting as a variation in autostarting malware.  More than anything else, the post left me more than a little says that the intruders found an application that was set to run when the system started, and then modified the application's import table by adding a reference to a malicious DLL.  It was the next sentence that left me confused:

It is almost impossible to find differences between the original version and the modified ones, as even their file sizes are almost identical.

The post then goes on to say that 4 of the 5 infected applications were discovered as the modified versions weren't signed.  However, there still seems to be more going on here, because adding a DLL to the import table of a .exe file, and then referencing the malicious function should make something of an impact on the size of the application, as well as other aspects of the system itself (MFT, USN change journal, etc.).

Speaking of stuff starting, Corey posted recently regarding some testing he'd done with an MSWord document that would launch an executable.

Something I really like about Corey's post is that there's enough detail in the way he presented the material to not only replicate what he did (if you can or want to get a copy of the file he used...).  Also, there's enough information in the post to create things like searches for the pattern after running LogParser against the Sysmon Event Log file, as well as to write Carbon Black watchlist queries.

Tuesday, May 05, 2015


Plugin Updates
Eric Zimmerman reached to me a little while ago and let me know that he'd taken a look at the AppCompatCache data from a Windows 10 system, and found that...wait for it...the format of the data was different from previous versions of Windows.  O.  M.  G.

Thanks to the heads up from Eric, I've updated the RegRipper plugins for parsing this data.  However, my testing was extremely limited; I had only one System hive file (from a Windows 10 TP VM that I'd set up) on which to test the parsing code.  A dearth of testing data has been an issue since I started writing tools, and it seems that even TaoSecurity has recognized the need for test data.

Interestingly enough, I happened across a System hive file from a Windows 2012 system, and the updates to the parser seemed to work just fine.  Again, I said "a" testing has been extremely limited.

When working with the AppCompatCache or "ShimCache" data, analysts need to remember the context of the information, and in particular, the time stamps in the data. In most cases, the time stamp is the last modification time for the file in question, from the file system metadata, specifically, the $STANDARD_INFORMATION attribute. It is NOT the date and time that the application was executed.

Dumping Passwords
Speaking of the Registry, I ran across this little gem that describes how to dump passwords in plain text from Windows 8.1/2012 systems.  I'm a big proponent for finding out what things look like on systems, and it's pretty clear reading through the blog post what an analyst would look for in an acquired image, to determine if something similar to what was described in the post had occurred on the system.

However, I'll put this out there...rather than hoping to find these indicators on a system, why not make IR scoping easier on yourself through the use of process creation monitoring at the endpoints?

Malware Persistence
Here's a good blog post on malware persistence.  There's some focus on MS's AutoRuns tool, so it's likely to be familiar to a lot of folks.  What I thought was interesting is the number of times we see the Run key being the point of persistence for malware; while many will suggest that this location is 'well known', there are also those of us who see it used time and time again, even when the incident is 'detected' through external, third-party notification.  Some may think that the Run key is passe, but hey, it still works, and works why not use it, right?

Every now and then, I still get an opportunity to analyze Windows XP and 2003 systems...most often, I tend to find myself working with Windows 7 and Windows 2008 R2 systems.  Working with older versions of Windows can sometimes necessitate the use of different tools in order to conduct analysis; specifically, when working with the Event Logs, they're in a different location, as well as in a different binary format.

When working with Windows XP and 2003 (and yes, Windows 2000) Event Logs (*.evt files), I'll use evtrpt and evtparse.  These tools were written specifically for the binary format of the *.evt files found on Windows 2000, XP, and 2003 systems, and are not intended for use against the *.evtx files found on Vista+ systems.

This is a tool I wrote a while back to provide me with information about the contents of an EVT file; how many records exist, how many source/ID pairs exist, and what date range do the events cover.  What's cool about this tool is that it doesn't use the MS API...which means that it can be run on Linux, and it doesn't rely on the header information of the EVT file to tell it how many records exist.

Evrtp is a command line tool, and takes just one argument...the path to the file you're interested in parsing.  If you just type the name of the tool at the command prompt, you'll get a message that says "You must enter a filename".  That seems to be pretty straightforward, and adding the full path to the .evt file of interest is all I need to do.

So, I run the tool against an Event Log file that I've extracted from an image, and one of the things I see in the output is the date range for the event records in that file:

Fri Sep 27 17:32:26 2013 to Tue Apr 28 17:37:58 2015

Cool, it covers the time that I'm interested in.  Above the date range in the output, I get a list of event sources and IDs, as well as a count of each.  For login attempts, the tool also breaks down the login/logoff type.  For example, I see the following entry:

Security                                      538,3    18938

What this tells me is that for the source "Security", there are 18938 events with ID 538 and type 3.

I ran the tool against the other Event Log files from the system, as well.  For the Application Event Log, the date range was:

Thu Jan 10 01:52:02 2013 to Tue Apr 28 15:36:04 2015

What I found most interesting from the output of the tool was this entry:

Symantec AntiVirus                               51        2

Remember the tool I use for Windows Event Logs, wevtx.bat?  The one that uses the eventmap.txt file?  Well, in that file, Symantec AntiVirus/51 event records indicate that the product detected malware.  Understanding the context of these event source/ID pairs can be extremely valuable, and the evtrpt tool can give you an idea of what pairs are available.  For McAfee, I'd look for McLogEvent/257 pairs.

Something of interest from the output of the System Event Log was:

Application Popup                                26       11
Application Popup                                44        1

So, hopefully by now you can see how useful this tool can be for a quick look at the Event Log files.

This tool operates similar to the evtrpt tool, but the output allows you to see more about the Event Log records.  Typing just the name of the tool at the prompt will show you the syntax information, along with example command lines you can use to run the tool.  I use this tool to parse through the *.evt file (or files) and add the entries to a timeline of system activity.  The command line to launch this tool does not take many arguments, because most of the data that you may want to include in each timeline entry (system name, user name, etc.) is included within each event record.

Why Do I Need The Event Source and the event ID?
Something I see a great deal of within the DFIR community is that Windows Event Log records are referred to only by their ID number.  Ok, you're probably what?  Who cares?  Well, it can be important...if someone says that they have mulitple event ID 4100 records, I would have to ask, which source?  There are a number of event IDs that have multiple different event sources, each of which can provide completely different context to the situation.

So What?
Why does any of this matter? Context is extremely important when conducting analysis, and in particular when communicating findings to other analysts, as well as to clients.  One example was mentioned earlier in this post...the time stamps in the AppCompatCache/ShimCache data is the last modification time of the file, from the file system metadata (the Mandiant white paper is only 5 pages long and is an easy read...).

Another example comes from the output of another RegRipper plugin...the LastWrite time for one of the subkeys from the USBStor key is just that...the key LastWrite time, which is analogous to a file's last modification time.  It is NOT the last time that USB device was written to.

So, when communicating findings from the Event Log (or, Windows Event Log on Vista+ systems), providing the event source AND ID can be extremely important for context.  If someone just says, "...event ID 4100...", then the very next question should be, "...which event source?"  When documenting findings in your case notes, include both the source and ID, as well as a reference, for (possible) inclusion in the eventmap.txt file.