Meetup, Tools and other stuff

Meetup
Just a reminder about our next NoVA Forensic Meetup, scheduled for 6 July.  Tom Harper will be presenting, and he's posted  his slides on his site.  Take a look at his slides, and download them if you want to bring them along.  Also, taking a look at them ahead of time will make the presentation itself go a bit more smooth, and leave more time for questions and interaction.

Location: ReverseSpace, 13505 Dulles Technology Drive, Herndon, VA.

Time: 7:00 - 8:30pm

Review
Corey Harrell posted his review of DFwOST.  Thanks for the review, Corey, and for taking the time to put your thoughts out there for others to see.

MBR

I've mentioned previously that I include a check for MBR infectors in my malware detection process, and I even have it on my checklist.  I discussed this recently with Chris Pogue ("@cpbeefcake" on Twitter), and he pointed me to the mbrparser.pl Perl script that Gary Kessler makes available via his site (the script can be found in the Boot Record Parsers archive).  Gary's mbrparser.pl script does more than just display the MBR; it also parses the partition table in a very readable manner, providing a bit more information than mmls from the TSK tools.

My own Perl script is used for something other than just displaying the MBR, and it doesn't parse the partition table...instead, it looks for sectors that are not all zeros, and will either list those sectors (in summary mode) or display them.  The thought process behind this approach is that many of the identified MBR infectors will modify the MBR with a jmp instruction, and copy the original MBR to another sector.  Some may even include executable code within sectors.  This is particularly useful when you have an image acquired from a physical disk and the first active partition is located at sector 63; usually, I will see sector 0 and 63 as non-zero, and maybe one or two other sectors.  Running the script in summary mode gives me an idea of how many of the sectors I will need to look at, and then running it in full mode allows me to have something that I can redirect to a file and even include in my report, should the need arise.  Even if nothing is found, that's useful, too...because now my malware detection process includes an additional step beyond simply, "I ran an AV scanner against the mounted image...".

Here are some links to disassembling the MBR:
Links
MBR disassembly
More MBR disassembly

Also be sure to check out Gary's page for other utilities, particularly if you're into SCUBA.

Speaking of MBR infectors, a recent MS Technet blog post mentioned a new MBR infector/bootkit called "Trojan:Win32/Popureb.E", which is apparently an update to previous versions of the identified malware, in that it infects the MBR.  Unfortunately, MS's recommendation is to fix your MBR using your recovery disk - I say "unfortunately" because without a root cause analysis, what is the likelihood that you "fix" the system, and the bad guy is then able to un-fix your fix?  Pretty high.  I've seen other MBR infectors get delivered via Java exploits...so if you don't figure out how the MBR got infected, how are you going to protect your infrastructure?  I'd suggest that the steps should be more along the lines of acquiring memory and an image of the physical disk, and then if you must re-provision the system, clean the MBR as suggested, but tag the system as such, and put a high priority on determining an overall fix.

Tools
Nick Harbour of Mandiant maintains a page with a couple of interesting tools, including nstrings and pestat.  Nick's also posted some FileInsight plugins, as well as interesting presentations, on that same page.

The Malicious Streams site includes a Python-based LNK file parser (as well as some interesting MacOSX-specific tools).

David Kovar has moved his analyzeMFT tool to a new location; take note, and keep an eye out for new tools/libraries...

What is "APT"?
Jason Andress published an article for ISSA about APT, what it is, and what the threat really means.  While I do think that the article gets a little too mired down in the origins and meaning of the term "APT", it does make a very valid point...regardless of what side of the fence you're on, APT is a very real threat.  Jason does point out some very important points with respect to defending against this threat, but he does mention tools without specifically identifying any particular tools to use.  I think that in doing this, he makes a point...that is, there is no security silver bullet, and one tool (or combination of tools) may work very well for one organization, but not at all for another.

I think that the most important point that Jason makes regarding defense is the idea of "defense-in-depth".  Now, I've seen where some have suggested that this doesn't work...but the fact of the matter is that you can't deem something a failure if it was never employed.

Jason mentions "security awareness"...this is important, but it has to begin at the top.  If you spend the time and effort to train your employees and raise security awareness, but your C-level executives aren't in attendance, how effective do you think that training will be?  If it's really that important, wouldn't the boss be there?  I attended two days of manager-and-above training for an employer, which was kicked off with a message from the CEO.  And guess what...every time I looked around throughout the two days, I saw the CEO there.  More than anything else, that told me that this stuff was important.  Security has to be top-down.

Something to point out that wasn't mentioned in Jason's article is that many of the things he mentions are either directly or indirectly covered in most of the legal and regulatory compliance standards.  Testing...training...having the right tools in place...many of these map directly to the PCI DSS.  Even defense-in-depth, when you include the computer security incident response team (CSIRT), maps to chapter 12.9 of the DSS.

Jump List DestList Structure
Jump lists are one of those new things in Windows 7 that many analysts are trying to wrap their heads around.  Jump lists provide similar functionality to the user as shortcuts in the Recents folder, as well as the RecentDocs Registry key, albeit in a different manner.  First, jump lists come in two flavors; Automatic and Custom destinations.  I'm not going to be really prolific about jump lists, but from a binary point of view, custom destinations are apparently SHLLNK structures run to together consecutively, one after another, where as Automatic destinations are streams within an OLE container (that is, each *.automaticdestination-ms file is an OLE container).  Each of the streams within the contain is numbered (with the exception of one called "DestList"), and follows the SHLLNK structure. You can open the automatic destinations jump list using the MiTeC Structured Storage Viewer, extract each numbered stream, and view the contents of the stream in your favorite LNK viewer.

There is very little (i.e., "none") information available regarding the structure of the "DestList" stream, but looking at it in a hex editor seems to indicate that it may serve as a most recently used (MRU) or most frequently used (MFU) list.  We know that the SHLLNK structure in the numbered streams contains time stamps, but from the structure definition we know that those are the MAC times of the target file.  So how does Windows 7 know how to go about ordering the entries in the jump list?

Well, I spent some time with some jump lists, a hex editor and a number of colored pens and highlighters, and  I think I may have figured out a portion of the DestList structure.  First, each DestList structure starts with a 32 byte header, which contains (at offsets 0x03 and 0x18) an 8 byte number that corresponds to the number of numbered streams within the jump list.

Following the header, each element of the structure is 114 bytes, plus a variable length Unicode string.  The table below presents those items within each element that I've been able to extract on a consistent basis, albeit via limited testing.

Offset	Size	Description
0x48	16 bytes	NetBIOS name of the system; padded with zeros to 16 bytes
0x58	8 bytes	Stream number; corresponds to the numbered stream within the jump list
0x64	8 bytes	FILETIME object
0x70	2 bytes	Number of Unicode characters in the string that follows

While the information represented in the above table clearly isn't all that's available, I do think that it's a good start.  Once further testing is able to determine what the FILETIME object represents, this is enough information to allow for inclusion of jump lists into timelines.