A Good Example (aka, The Need for Training)
I was reading Brian Krebs' blog the other morning, and found an interesting story...interesting in light of a lot of the reports that have hit the streets recently regarding IR and forensics response.

What stood out in the article was:

...discovered on Feb. 5 that the computer used by their firm’s controller was behaving oddly and would not respond. The company’s computer technician scoured the system with multiple security tools...

...and...

The following Monday, Feb. 8, United Shortline received a call from the Tinker Federal Credit Union at Tinker Air Force Base in Oklahoma, inquiring about a suspicious funds transfer...

Sound familiar? Outside third-party notification of the issue, untrained staff responding to the incident, stomping on everything (i.e., scouring...with multiple security tools)...not too far off from what some of the reports have been illustrating, and what many have seen on their own. Oh, yeah, and the bad guys got away with about half the money.

And that's not all. Brian also posted on an incident at the city of Norfolk, VA (terminal23 picked up on the story, as well, from Brian); this one also has some prime quotes. A city official was quoted as saying, "We speculate it could have been a ‘time bomb’..."...while the investigation was still on-going, a relatively high-up official is speculating. It appears that the primary indicators thus far is that files were deleted from the system32 directories on what may be as many as 784 PCs and laptops.

There appear to be some indications that the malware infection...keeping in mind that there doesn't seem to be anything definitive...originated from a print server;

However, an exact copy of the malware on that server may never be recovered, as city computer technicians quickly isolated and rebuilt the offending print server.

Look, I understand what folks are going to say..."hindsight is 20/20". However, if anything, these stories should be good examples of what NOT to do when faced with an incident. I know that a lot of folks would say, it's easier to just rebuild the system...but look what happens when you use that approach. And when you rebuild the system and have no idea how the incident occurred, then how do you prevent it from happening in the future. It appears from the article that law enforcement was contacted...but why, and to what end? I understand that someone wants this treated as a crime, but it's generally not helpful if your house is burglarized to burn the house down and then call the police.

But again...this is nothing new. Folks who respond to incidents and try to assist customers on an emergency basis have been saying this for years...be prepared, because it's not if you get hit by an incident, it's when. I completely understand that you can't completely know everything, but EMTs are prepared for most types of incidents they would encounter, right? In the case of most victim organizations, though, it's not so much that they got hit, but how they reacted.

What could they have done better? After all, one shouldn't point out deficiencies without offering up a solution, right? Well, going back to article on Tinker Federal...a lot of folks would look at me and say, "hey, at the time there was nothing to justify the time and expense of imaging the system." Okay...I track with you on that...but there's more to IR than imaging systems. How about having a tool set in place to collect specific information, and gather selected files? Make it automated so that it works quickly and efficiently, every time. That way, if you need it, you have something...if you don't need it, fine.

It's a matter of education and training. If you need an example of what to look to for training, try EMTs or the military. EMTs have a defined triage process for assessing victims. The military has immediate actions...stuff we learned to do because the time would come when you needed that particular skill, but you don't have time to look it up in a book or on Wikipedia. That time would be at 3am one morning, after you'd been without sleep for over 2 days, had little food, and needed a particular skill that could save your life, and the lives of your fellow service members.

Rootkit Detection via BSoD
Seems there's a bit of malware being (that had been) detected due to a BSoD after an update. Apparently, after updating with the MS10-015 patch, some folks were experiencing BSoDs...at least in some cases, this had to do with the Tidserv on their system; the malware had infected drivers, and then those drivers made calls to invalid RVA addresses.

Symantec - Backdoor.Tidserv!inf
MS calls it Win32/Alureon; this one is a lot of fun...according to MS, it hides itself (think rootkit) by intercepting file system driver I/O packets.

The really good news is that, according to MS, the code has already been updated to no longer use hard-coded RVAs...which means if your system gets (re) infected, you're not likely to be able to use a BSoD to detect what your AV missed...

MMPC
A recent posting regarding Pushbot over on the MMPC made for some good reading. I picked up several interesting things from just this one posting; code reuse, passing around what works, perhaps some sloppy setup (leaving non-functioning code in the program...although that may be a red herring). The fact that the base code is open and shared, and used/modified by a number of different folks really highlights to me why the good guys and victims always seem to be playing catch up.

The MMPC posting says that the purpose of malware like this is to infect as many systems as possible. On a large scale, you might expect this malware to be somewhat noisy, but on a smaller scale, not so much...infect a system, reach out to an IRC server, spread via some mechanism. There won't be a lot in the way of re-infections. Oh, but wait...some variants appear to write a value to the ubiquitous Run key...nice! Looks like you've got an enterprise-wide detection mechanism available to any domain admin with a copy of Notepad!

What really isn't stated explicitly in the posting is even more telling. While this malware is described as being "old school", it still uses multiple propagation mechanisms. This has apparently made it enough of an issue that MS has added Pushbot to the MRT.

Thanks
Now and again, I get thank yous from readers of my books and/or blog, mostly directly into my inbox. I greatly appreciate the time folks take to reach out and say these things. I also sometimes get a comment or TY that I'd like to share with others, in part because it helps validate some of the things I do or put out there.

I received the following recently from Lt Chris Taylor of the City of Richmond, Indiana Police Dept (posted here with his permission):

I also want to thank you for your contributions to the field of Digital Forensics. Between your book, your blog, and the information you provide on the various list serves I subscribe to, the info and tools you’ve provided have shaved countless hours off of processing cases, making me more efficient as an examiner. Thanks again!

Thanks, LT! I greatly appreciate your words!