Wednesday, November 04, 2009

Link-alicious

Thanks to Rob Lee's tweets, I read about AccessData's new Registry Summary Reports recently. These seem like baby RegRipper plugins...not quite there yet. I contacted some marketing guys from AD and they said that Registry Viewer has had this capability for years...I never knew about it when I was using FTK v1.71 or 1.8 (and I was too busy pulling my hair out just trying to install v2.0!!)...guess I just missed it.

ImagineLan has an SRP Explorer utility that looks quite interesting, allowing you do to do diffs of Registry hives across Restore Points. Interesting.

From the MMPC, a post regarding the MSRT October release, with a case study.

Rifiuti, the tool from FoundStone for parsing Recycle Bin INFO2 files, has a version available for Vista Recycle Bins called rifiuti2. This is actually a rewrite of the original code, according to the Google Code page. And yes, there is a version available for Windows.

Anyone caught the most recent edition of Captain Forensics??

Addendum: Chris Novak had an excellent (albeit short) article published on the Fundamental Failures With IR Plans...essentially, not having/testing one. Chris makes an excellent point...although war stories are sexy (re: fascinating) and writing is boring, the fact is, you have to have an IR plan. I was talking to someone recently about a company that stores CVV data, and does their own PCI self-assessment...and passes. I bet they also check "yes" when they get to the PCI DSS requirement 12.9...

I found some interesting stuff on Ophacki recently, starting with this analysis from Joe Stewart, and then moving on to the ISC write-up. Folks, if nothing else, this sort of thing demonstrates the lengths malware authors can and will go to in order to keep their stuff on systems. This bit of malware is a link hijacker, which essentially means that it's relatively harmless...however, more and more customers are asking folks like me (and the malware experts I work with) to determine if the malware has the capability to steal data, and if so, what did it take. First, this ties in to the IR plan article...if you have no plan and do nothing but shut the system off (i.e., capture no volatile or network traffic data), my ability to help you answer those questions is limited. Your IT staff are closest to the incident...it may take me 24-48 hrs to get there, depending on flights (and contract negotiations). If you have a plan and trained response staff, you can at least collect the data...

Second, if you haven't hugged your malware analyst today, do it now. I mean, seriously...look at how complex Ophacki is...it reportedly hides in memory by destroying the PE header. It doesn't decrypt the strings it needs in memory until it needs them, and then it deletes them when it's done. It also deletes the SafeBoot key, and reportedly hooks the APIs to delete Registry keys so that you can't delete the keys it uses for persistence. It also removes Zeus.

In short, there is a lot of sophistication for a simple link hijacker...which tells me that there's some kind of economy at work here...someone REALLY wants to make money!! What if the intent were different? What if the author really wanted to steal data? What if the malware was used to determine the type of system it was on...if a home user's system, look for indications of web-based purchases (or just sniff the keyboard), look for tax returns, and then turn the system into a zombie.

My point is that malware is getting more and more sophisticated, and malware authors are responding not only to standard business practices (i.e., Conficker spread via network shares) but also to some of the response procedures - some malware does not write to disk, but instead remains persistent in memory because the systems are rarely rebooted. Some folks recommend simply nuking the box from orbit...clean and reinstall...but malware authors know that the box will likely be put right back in place with the same holes and vulnerabilities, because that part of the re-installation plan is very often missed or skipped, because there is no IR plan.

5 comments:

Rob Lee said...

Was not impressed with SRP Explorer. It crashed everytime I tried to do something. Concept is good, but clearly beta (alpha?) code.

--Rob

Rob Lee said...

Also, it took me awhile, but was able to test the RSR reports. Their documentation was shoddy and didn't match running them in old FTK 1.8. The output reports are linked via an Index.html page with each output RSR creating its own html page. I found that slick to easily browse to what you are looking for.

H. Carvey said...

I just installed the demo version of RV, and put all of the RSRs in the data directory, per the instructions. I opened an NTUSER.DAT file in RV, but could not access the Manage Summary Reports functionality, as it was greyed out.

I cannot compare the tools, nor can I see what the RSRs actually do.

Dennis said...

Thanks for the Captain Forensics link. Even though it's a time-distraction at least it's on-topic.

Dennis said...

Keydet89, the reason you're not seeing the RSR-Manage Summary Reports function is that it's not available in the demo version (I have the registered one and compared it).

From the RV user manual:

In Demo mode, the following program features are disabled:
􀂊 Common Areas view
􀂊 Report view
􀂊 Generate Report function
􀂊 Decryption and interpretation of protected storage areas