Friday, September 09, 2011

Updates and Links

NoVA Forensic Meetup
The most recent NoVA Forensics Meetup was a great time! Mitch Harris gave a great "Botnets 101" presentation and opened the door for 201.  Mitch described botnets and their command-and-control (C2) structures, and is leaving mitigation techniques for his follow-on presentation.  A huge thanks to Mitch for presenting, and everyone for showing up, especially those who came by because they were in the area.  We're looking forward to having Mitch come back for that follow-on presentation in the future.

BIOS Malware
Speaking of Mitch's presentation, he also mentioned malware that infects systems by writing to the BIOS.  Oddly enough, I ran across Mebromi this morning, which Norman describes as a "BIOS-flashing Trojan". 

An excellent point brought up in the writeup is also something that we discussed during the meetup; that is that the reason why we're not all infected with malware that writes to the BIOS (or to the GPU on our graphics card, etc.) is that this sort of malware is "hard to do", because it's very hardware-specific.  In fact, the writeup also indicates that the Trojan attempts to modify Award BIOS's only.  Mebromi also apparently infects the MBR, as well.

Here is Symantec's writeup on Mebromi.

Okay, this is the last thing I'm going to say about malware in this post...seriously.  I ran across this ComputerWorld article this morning, which mentioned that the same spearphish attack code used against RSA had also been used against other organizations; in fact, the first sample of that code had actually been submitted on 4 March, whereas (according to the article) it wasn't until 19 March that a sample was submitted from someone at EMC (the company that owns RSA). 

Folks, what this tells us is that those tools that we use to quickly gather intelligence about stuff we find on our systems can then be used against us.  In spearphishing attacks, you can be sure that the attackers know exactly to whom the emails were sent...that's sort of the nature and definition of a spearphishing attack, and is also why we don't simply call it "random-spray-and-pray".  Remember, "public" websites are usually exactly that...public.  And available to everyone.  This is why you might want to develop an organic, in-house malware analysis capability.

Also, there was apparently some metadata analysis of the actual spreadsheets that had been submitted, as well...take a look at the article and see if you agree with what was said about that...

Jump Lists
The new 4n6k blog has a post up that extends Jump List Analysis by adding a whole bunch of AppIDs.  I posted recently regarding using timeline analysis to fill in the gaps in analysis when you're either attempting to determine the app associated with an unknown AppID, or if the user had deleted the application itself prior to the acquisition of the system. 

One of the comments to the blog post that I mentioned above was along the lines of, hey, locating indications of apps being run has been discussed thought along those lines is, okay, but do we do it enough?  Seriously.  How often do we really share analysis techniques, or findings?   Something may have been discussed before...but where, and with whom?

What would have happened within the community if no one took USB device analysis any further after the first research was published?  What if Rob Lee had never decided to take what was published a step or two further?  What if the first iterations of the Volatility Framework had never been developed?

It's important that we discuss these things, and keep discussing them.  The problem that we face as a community is that nothing about what we do is static; everything's changing all the time.  Discussing analysis techniques and findings allows us to not only engage other analysts who may not have seen what we've seen (or didn't know that they did), but it also allows us to metaphorically go beyond the next ridge and see if the world really is flat.

ProDiscover recently turned 7...that's right, version 7 was released, adding MacOSX support (HFS+ file system, DMG images), EVTX Event Log format support, and there's a Fedora Linux live boot disk, as well.  Chris Brown has graciously provided me with a license for ProDiscover IR since version 3, so I've seen this application go through a lot of growth, as Perl ProScripting support was added, as well as support for parsing PST/OST files.  Just prior to version 7, Chris added support for parsing Windows 7 Jump Lists, making PD the first commercial forensic analysis application (that I'm aware of) to support parsing this artifact.  ProDiscover was also the first commercial app to include native parsing of VSCs...right clicking on the partition within the app gives you a list of VSCs to choose from, and the ones you selected would appear as volumes/drive letters right there in the app UI.

Corey's got a great post up called "What's a Timeline", which is a very good post that helps explain what a timeline is, or should be.  It doesn't matter whether you're new to timelines or not, it's worth a look.

ESEDB Format
BugBear posted recently regarding using Joachim Metz's libesedb project tools to parse data from the Windows Desktop Search database, based on the Extensible Storage Engine (or 'ESE').  Joachim also wrote a paper that documents the format of the database.  While Joachim's tools are Linux-based, Mark Woan provides his EseDbViewer for Windows systems.

From reading the materials available, it would appear that the ESE DB format, particularly for the Windows Desktop Search, may provide some very interesting forensic artifacts.  It would be good to hear if any analysts out there are already using information from within the ESE database in their examinations.

If you're interested in developing your own code, iiobo has an ESE library and toolkit (C++/C#) available.


Dave Nelson said...

"Remember, "public" websites are usually exactly that...public. And available to everyone. This is why you might want to develop an organic, in-house malware analysis capability."

Totally agree that there should be in-house malware analysis at the enterprise level.

But as this pertains to sharing malware hashes on public data stores, doesn't that defeat every common goal related to open source intelligence and the synergy's that come from more than just your in house MIRT seeing the data? Every hash submitted means someone else will get to build a histogram and risk intel based on filename, date and AV report. If the concern is tying the compromise to your company, just submit from an alternate IP but don't refrain from posting malware hashes.

H. Carvey said...

...doesn't that defeat every common goal related to open source intelligence and the synergy's that come from more than just your in house MIRT seeing the data?

If they keep it to themselves, sure. The key would be to develop a sharing mechanism away from sites like those mentioned.

mcclintock said...

ESE is also used in Active Directory and in Exchange server.

H. Carvey said...

ESE is also used in Active Directory and in Exchange server.

What databases (name, path) would you parse?

Jimmy_Weg said...

Harlan, I examine the Windows.edb file somewhat regularly. In almost every instance, I do so to try to discover the path of a deleted graphic for which only a Thumbcache image remains. The edb may contain the Thumbcache ID of the original file and reveal its path. Although I haven't had a lot of success, I have had a few, and identifying a path may be significant, e.g., to show intent of saving an image.

I use Mark Woan's tool, but also have been using Greenspot's WSia, which is designed to assist in cases such as I described above. There's a good explanation of the concept at I also use Greenspot's dmThumbs, which has a built in feature to resolve the Thumbcache IDs.

mcclintock said...

%SystemRoot%\NTDS\ntds.dit for Active Directory. I'm guessing you'd have to grab it while in Safe Mode or AD Restore Mode.

%ProgramFiles%\exchsrvr\MDBDATA\pub1.ebd and priv1.edb for Exchange.