Automated Web-Based Malware Behavior Analysis
I just watched a video presentation from September's OWASP conference. The presenter, Tyler Hudak, talked about the Truman-based hybrid sandnet he created to automate the analysis of web-based malware. He references Google's The Ghost in the Browser paper, as well as the Honeynet Project. One tool he used to help automate things in Windows is AutoIt, something I had not heard of before, but it sounds handy. The demo also shows a tool called InCtrl5, a utility for Windows that monitors changes to your system, primarily for use when installing some new program. I guess it's used to compliment the usual Sysinternals tools, so maybe it has some extra features that Tyler finds useful.
Some of the problems this approach is trying to solve are browser-dependent obfuscated JavaScript, plug-in dependencies (like Flash), multiple redirects, etc. All of these issues make malware analysis more complex and time consuming, so any automation you can get away with is a big help. The demo at the end is pretty cool, but he glossed over how the information from the automated analysis is presented to the user. I'm guessing it's not (yet) in a pretty report format. Either way, you still need someone with the right knowledge to analyze the output and decide what to do with it to help defend your network.
Malicious CHM file targets PGP
Let's not forget that CHM files can be dangerous. They can contain embedded executables that get launched automatically when you open them. This post on SANS ISC details a particular malicious CHM file that was sent out via email. After some investigation, it was determined that the program it ran specifically targeted PGP keyrings.
The code searched for these files (.pkr and .skr) and copied them off to the attacker's system. To really make use of a PGP keyring, you need the passphrase. Well, this is why the malware came bundled with a keylogger, just in case you happened to be using PGP while it was running. The ISC post also notes that it collected .doc files, which could be an attempt to harvest documents that users created to help them keep track of their passphrases.
I'm not sure if I see enough evidence to agree with the conclusion that the attacker was simply trying to map relationships between PGP users, but I guess that is a possibility. Do recent versions of PGP even use these same keyring files?
G-Archiver is evil
This is a great lesson in why not to blindly trust random software that you find on the Internet. G-Archiver, a program created to help users locally save their Gmail messages, has a piece of code in it that sends your Gmail login and password to the author. You can see a scary screen shot of his inbox, since the guy had his own Gmail credentials hard coded right into the program, which was obviously discovered.
The details are at SANS ISC (source code) and Coding Horror (screen shot).
JavaScript Packers
This article by SecureWorks, titled "The Packer 2.0 Threat", is a good introduction to and overview of some of the most popular JavaScript packers. It discusses both the legitimate (although possibly misguided) uses of packers, as well as their role in obfuscating malware. The packers mentioned in the article include: Dojo ShrinkSafe, MOOtools, YUI Compressor, JSMin, and the Dean Edwards Packer.
Basically, the author argues that packing JavaScript leads to several unintended consequences that are bad for security. The most obvious problem is that it becomes much more difficult for network traffic inspection tools, including IDS, to tell the difference between friendly and malicious code. Other techniques, such as gzip compression, are probably good enough to improve bandwidth efficiency.
Software Reverse Engineering Tool Library
This is pretty cool. It's the new Collaborative RCE Tool Library, a nearly comprehensive directory of reverse engineering tools. Not only does it list the tools and provide links to download them, the directory also has pretty good descriptions and resources to learn more about each topic. The tools are conveniently sorted by target type (e.g., Java, Flash, Linux) as well as tool type (e.g., debuggers, PE editors, unpackers) and the whole thing is searchable, which makes it pretty easy to find what you need. (Although, right now the search seems to be broken.)
Perhaps the best feature of the RCE Tool Library is that it's collaborative, meaning users can improve upon entires, add new ones as new tools are created, and generally keep everything up to date. That will definitely help keep the directory from becoming stale.