Size Matters

Yes, it does, and sometimes smaller is better.

Here's why...the other day I was "doing" some analysis, trying to develop some situational awareness from an image of a Windows 2008 SP2 system.  To do so, I extracted data from the image...directory listing of the partition via FTK Imager, Windows Event Logs, and Registry hive files.  I then used this data to create a micro-timeline (one based on limited data) so that I could just get a general "lay of the land", if you will.

One of the things I did was open the timeline in Notepad++, run the slider bar to the bottom of the file, and search (going "up" in the file) for "Security-Auditing/".  I did this to see where the oldest event from the Security Event Log would be located.  Again, I was doing this for situational awareness.

Just to keep track, from the point where I had the extracted data sources, I was now just under 15 min into my analysis.

The next thing I did was go all the way back to the top of the file, and I started searching for the tags included in eventmap.txt.  I started with "[maldetect]", and immediately found clusters of malware detections via the installed AV product.

Still under 18 min at this point.

Then I noticed something interesting...there was as section of the timeline that had just a bunch of failed login attempts (Microsoft-Windows-Security-Auditing/4625 events), all of them type 10 logins.  I knew that one of the things about this case was unauthorized logins via Terminal Services, and seeing the failed login attempts helped me narrow down some aspects of that; specifically, the failed login attempts originated from a limited number of IP addresses, but there were multiple attempts, many using user names that didn't exist on the system...someone was scanning and attempting to brute force a login.

I already knew from the pre-engagement conference calls that there were two user accounts that were of primary interest...one was a legit account the adversary had taken over, the other was one the adversary had reportedly created.  I searched for one of those and started to see "Microsoft-Windows-Security-Auditing/4778" (session reconnect) and /4779 (session disconnect) events.  I had my events file, so I typed the commands:

type events.txt | find "Microsoft-Windows-Security-Auditing/4778" > sec_events.txt
type events.txt | find "Microsoft-Windows-Security-Auditing/4779" >> sec_events.txt

From there, I wrote a quick script that ran through the sec_events.txt file and gave me a count of how many times various system names and IP addresses appeared together.  From the output of the script, I could see that for some system names, ones that were unique (i.e., "Hustler", etc., but NOT "Dell-PC") were all connecting from the same range of IP addresses.

From the time that I had the data available, to the point where I was looking at the output of the script was just under 45 min.  Some of that time included noodling over how best to present what I was looking for, so that I didn't have to go through things manually...make the code do alphabetical sorting rather than having to it myself, that sort of thing.

The point of all this is that sometimes, you don't need a full system timeline, using all of the available data, in order to make headway in your analysis.  Sometimes a micro-timeline is much better, as it doesn't include all the "noise" associated with a bunch of unrelated activity.  And there are times when a nano-timeline is a vastly superior resource.

As a side note, after all of this was done, I extracted the NTUSER.DAT files for the two user profiles of interest from the image, added the UserAssist information from each of them to the main events file, and recreated the original timeline with new data...total time to do that was less than 10 min, and I was being lazy.  That one small action really crystallized the picture of activity on the system.

Addendum, 27 Sept:
Here's another useful command line that I used to get logon data:

type events.txt | find "Security-Auditing/4624" | find "admin123" | find ",10"