Stuff

MaaS
For quite a while now, when I've been presenting or discussing the state of DFIR with others, I've talked about how attackers and threat actors have long since moved away from digital joyriding on the Information Superhighway (how's that for a cliche?) and how cybercrime is more targeted and focused, and has an economic stimulus.  In many cases, I've mentioned this in the "us-and-them" context, how those of us on one side of the fence are faced with strict (or more often, no) budgets, while those that we're working against have a monetary motivation to not only innovate, but to do so rapidly...to fail quickly, learn and move on.

Back in the day, I knew some folks who wrote custom rootkits, albeit for a fee (I've always wanted to use albeit in a sentence).  That's right, skilled programmers who were tired of the pointy-haired bosses that they worked for, so they hung out their own cyber shingle and began writing custom rootkits for a fee, in order to support themselves.

I ran across this HelpNet Security article that describes the pricing structure for a number of available services, including infections.

Malware (or "mallware", but you'd have to take a drink...)
This section's title is based on my mispronunciation of the word "malware" (I was saying "mall-wear") during my presentation at OSDFC this past June, which led Cory Altheide to start a drinking game.  And here I was thinking that it was my mad presentation skillz that got the back of the room excited.  ;-)

Anyway, Claus is back with a great post on some malware detection resources, stuff you can use particularly if your analysis systems are "air-gapped" from other networks, and in particular the Internet itself.  It's always good to have resources like these in your toolkit, or just your back pocket, as you never know when you're going to need them.

Thoughts on WFP
Chris Pogue (@cpbeefcake on Twitter) has a new post up on the SpiderLabs blog, entitled "Manipulating Windows File Protection and Indicators of Compromise".  As you can see in his post, it is based in part on a discussion Chris and I engaged in a while back regarding the topic of malware and disabling WFP.


Chris makes the following statement in his blog post, regarding IOCs:


"Apart from dllhost.exe being present, apart from the timeline, there were not any IOCs of modification."

I would suggest that beyond what Chris mentions, there are IOCs of this sort of activity, particularly the specific activity that Chris outlined in his post.  Chris even goes so far as to mention in his post that I include a discussion of this topic in WFA 2/e, on pp.328-330; on those pages I point out a means for detecting files that were changed using the process that Chris describes in his post...in short, identifying some IOCs of this sort of activity.  Chris even describes how the target file (that was modified) has a different hash after the modification.  While there may not be anything immediately obvious in the volatile data from a compromised system, there is definitely at least two IOCs; MFT entries Chris describes, and the "new" hash of the modified file.

One of the steps I included in my malware detection checklist is to run a "WFP check".  Essentially, what this is is a Perl script that I wrote that accesses a mounted image, goes into the system32\dllcache directory, gets all of the names and hashes of the files.  Then, it goes into the system32 directory, locates any file of the same name as one of the ones found in the dllcache dir, gets the hash and performs a comparison.  I decided to limit the second-level search to the system32 directory because there a number of false positives on systems that have updates...you'll get a number of "hash mismatch" messages for older versions of files that have since been updated.

I haven't posted the Perl script that I use because, to be honest, I haven't seen where anyone's interested in this sort of capability.  I use it as part of my malware detection process...it's quick, it's easy to use, and it gives me a quick look at something that could very easily turn up a smoking gun, if not the smoking gun.  Another reason I haven't released the script on a wide-spread basis is that I have found a lot of folks who...have had trouble...using some of my more esoteric tools.  I recently had someone ask for a copy of mbr.pl, and once they had it, they ran it against a .vmem file.  And when many folks can't get the tool to work as it should, or as advertized, they tend not to contact me about the issue.

Further, in my experience, this issue (WFP being disabled) isn't one that's easily understood by a number of analysts, and when the topic is first presented, it can lead to a good bit of confusion.  For one, WFP is not intended to be a 'security' mechanism...rather, it is intended to protect the user from inadvertent actions from...well...the user.  As Chris pointed out in his post, the capability to easily circumvent this functionality has existed for some time.  Also, understanding how the detection process makes use of available IOCs can also lead to confusion.

Virtual Systems
For anyone who's done any testing of any kind, in particular of exploits and compromises, it's always nice to have some virtual systems around that you can test against.  For folks who use VMWare and VirtualBox, there are sites where you can go and download virtual machines...but most of them are non-Windows based systems.  Well, if you're using VPC, you can go to Microsoft and download IE App Compatible VHD systems; these are intended for testing web sites, but I'm sure that even with the baked-in operation limits that Claus mentions, these are a lot more accessible than a full-on MSDN subscription (particularly because several of the systems are fully patched up to a certain date).

Linkz
Here's a good post on CD/DVD Forensics from one of the "Hacking Exposed: Computer Forensics" authors.  One thing that really stood out about this post was the statement:

At G-C (my company) we try to have an internal training topic for about 30 minutes to an hour every day (that I'm in the office).

This is an excellent way to share information, particularly about exams and anything new that some has learned...or even something that's not new.

Ken Johnson has posted some really good information regarding a Windows 8 forensic overview.   Not only is this just some great info, but it's very timely...I'm putting together a submission for the 2012 SANS Forensic Summit, for a presentation where I will be discussing forensic analysis of Windows 7 systems, with a good deal of information regarding Windows 8, as well.  Take a look at what Ken mentions about the Windows 8 File History feature...pretty interesting stuff.  With that, and accessibility of "the cloud", incident responders may have something of a scoping challenge on their hands.

What's Old is New
I caught a thread on a popular list recently regarding the topic of ADSs...NTFS alternate data streams.  It's simply amazing to me, given the amount of information available on the topic,that more folks don't know about them.  What this can lead one to think is that if folks (IT/IR staff, forensic analysts, etc.) don't know about these artifacts, then they may not be looking for them.

After all, the capability to create arbitrary ADSs has existed in NTFS since the early days of the file system.  Until Vista, there were no tools native to the platform that allowed admins to view the existence of arbitrary ADSs...and even then, it's a CLI capability (i.e., dir /r).  Tools and even scripts can be launched from within ADS, and the toolkit for the Poison Ivy Trojan includes an option to use ADSs. 

Books
I was on Amazon recently, and ran across the listing for WFA 3/e.  I'm told by the publisher that this book is due to be out on or about 7 Feb 2012, and I'm really looking forward to it.

However, there are a couple of things I wanted to address about the book.  First, this one looks almost exactly like WFA 2/e.  I've already run into instances where owners of WFA 2/e don't pick up on the differences in cover art between that book and WRF.  Now, the third edition is coming out, and it's going to be even harder to tell which one you have.

Second, the third edition is NOT (I repeat...NOT) intended to replace the second edition...instead, it's a companion book.  That is, if you have one, you'll want the other.  The third edition focuses much more on Windows 7, and includes several new topics.  After all, there was really no point in reprinting the content regarding the PE file format if it didn't change, right?

Registry Analysis
I ran across this interesting blog post recently that discusses how the TypedURLs key can be populated, depending upon the version of IE used.  This simply shows, once again, that the version of Windows (and now IE) that you're dealing with is important, particularly when you're looking for assistance.

Part 2 of this article states that it is, "...becoming increasingly common for some of the TypedURLs entries to be written by malware and not typed by the user at all."  Interesting.  So the question then becomes, when conducting analysis, how do you tell the difference?