Searching for Hashes of Malicious Files (APT – Aurora)

A couple weeks ago I posted a blog article with some sample file hashes and domain names associated with the recent Google hacks (think APT or Aurora).

Since then I’ve had quite a few people ask me, if you have a system that you suspect might have been compromised, how do you search that system for files that are malicious if you have a list of hashes that you know are malicious? In other words, you have a list of hashes and you want to know if there are any files on your file system that has the same hash value.

Disclaimer – before we continue you should know, hashes of malicious files are just one way of attempting to discover if your system has been compromised. Especially when dealing with a threat like APT, which is highly intelligent and adaptable, you have to know that if the threat knows that you’re on to them and that you’re looking for a specific set of hashes, that they’re smart enough to adapt. What will they do, they’ll change their malicious files so the hashes change as well. There’s no doubt this is a limitation. But utilizing the technique we’re about to describe you can at least start to eliminate some of the low hanging fruit. You may also want to investigate the projects involved with fuzzy hashing. This may be an alternative to some of the standard techniques described here.

Ok, now that you’re ready to start examining your systems for malicious files, here is a process to consider:

Step One: Assemble a Text File of Known Malicious Hashes. The first step you need to follow is to gather a list of hashes of known malicious files. This will be the list of hashes you’re scanning your system for. Remember, the value of your scan will only be as good as the list of hashes you have. A starter list of MD5 hashes is currently being hosted at Enclavesecurity.com and can be found here if you’re looking for a list to get you started. This list certainly is not comprehensive, but at least is a place to consider building your first list from.

Step Two: Decide Which Hashing Tool to Use. There are a number of good tools that you can use to scan your system and to generate hashes of all the files on your file system. Many of these tools are commercial and there are open source tools for this as well. On the commercial side tools like Tripwire, Lumension, and Bit9 are quite effective at this. There are certainly others, but many of you are already using these tools, so you might as well take advantage of them. Unfortunately there are also many of you that simply cannot afford these tools. If you’re looking for a good open source tool to use to start scanning your systems, let me recommend MD5Deep. This is a tool in the public domain that is especially useful for this purpose. While there’s not enough time in this post to talk about how to use the tool, we’ll post more on it later. You could also consider rolling your own scripts, using PowerShell or shell scripting to generate these hashes as well (but I still recommend MD5Deep – it’s cross platform, supports recursive file scans of directories, and natively interfaces with a number of hash databases).

Step Three: Scan Your System. Now that you have your list of hashes for malicious files and you have your scanning tool, now it’s time to scan your system to see if any files with these hashes exist on your system. This is the basic part of the exercise – do you have malicious files on your system or not? Depending on the tool you’re using this process will be slightly different, but in the end you’re trying to determine if you have a compromised host. Auditors – you should be asking companies the control question, if law enforcement approaches you with a list of hashes like we’re describing here and they say you need to check your system to see if any of these files exist on particular hosts in your environment, how would you look for the hashes? Ask to see their process in action (we want more than tabletop reviews here).

Step Four: Automate System Scans. Finally once you have your tool working in a manual mode, automate the scans. This is one of the major principles of the 20 Critical Controls / Consensus Audit Guidelines that we talk so much about. Manual scans are fine when you need to use them – but how much better is it if you could implement a tool that would be constantly scanning your systems and would notify you one of the hashes were discovered? Automation is key.

While there are certainly other ways to go about looking for malicious files on your file system or indicators of compromise on a system, examining file hashes certainly has to be part of your arsenal. If you’re auditing a system, knowing that you have a control in place to scan for signatures of known bad files has to be part of your toolkit. Traditionally we’ve done this with anti-malware tools, but unfortunately many of the large anti-malware vendors still don’t let you know which hashes they’re scanning for and they don’t give you the ability to add hashes that you’d like to scan for in their tools. Thus we’re left to our own devices to discover if files with these signatures are still on our systems.

Hopefully putting this tool in your toolkit gives you one more angle to consider when looking for indicators of a compromise on your systems.

20 Critical Controls, “Aurora”, APT, and the Google Hack

Obviously there has been a lot of discussion in the news, on blog posts, even tweets, on the issue of the Aurora attacks and what they mean. This is certainly not a new threat. Evidence of this threat can be seen back to at least 2008 if not earlier (if you consider Titan Rain or other operations), but until now no one wanted to talk about it publicly. But in the background work has been in progress to discover techniques to stop the threat.

Enter the 20 Critical Controls…

In 2009 the Consensus Audit Guidelines / 20 Critical Controls were released to prioritize the information security controls that need to be implemented in order to combat known attacks (ie. think Aurora or APT). US federal government and commercial systems were being compromised by this threat and others and something had to change. But what was the tipping point? Why were these controls introduced in 2009? The tipping points were these advanced, directed attacks against US federal systems by foreign entities. That’s what tipped the scales and precipitated the release of these controls.

So let me say what a lot of us have been dancing around for the last two years – there are dedicated, focused, well-funded attackers who are successfully breaking into government and commercial network systems and the 20 Critical Controls were introduced to stop this threat. It’s real, many of us have seen it first hand, and it’s hard to get out of your systems. Call it APT, Aurora, whatever, the 20 Critical Controls were put in place to stop these hacks.

Sales pitch time – so why should you care about the 20 Critical Controls? Why should you learn more? Because this is a real threat and it seems to be getting worse. The controls are meant to prioritize your resources and encourage you to automate an effective response. They’re more than just a list of good things to do, the purpose behind the controls is to change our way of thinking about how we protect our systems. One great place to start the education is here:

http://www.sans.org/security-training/20-critical-security-controls-in-depth-1362-mid

There have been a lot of good people commenting and posting information on the topic as well. If you aren’t following this information already, here are a couple other sources you might look into as you’re learning more about these attacks:

Mandiant M-Trends & Blog (http://blog.mandiant.com/)
Enclave Security Blogs (http://enclavesecurity.com/blogs/)
TaoSecurity Blogs (http://taosecurity.blogspot.com/)

But my biggest complaint however, and I’m sure I’ll rant more about this later, is that we are simply not sharing enough information as a community on this subject. We have to share more. We all have reasons why we’re not sharing the attack signatures we’ve seen – some reasons are commercial, some are because of fear of retribution, some are due to contractual restraints. I get it. But if we’re going to be successful at combating this threat, we have to share signatures and methodologies. But I’ll leave the rest of this rant for another day…

Some people are already sharing, here are two of the few postings I’ve found publicly on the subject. Take advantage of these when you find them, there aren’t many people sharing. Or if you are sharing signatures or indicators of compromise, drop me a note at james.tarala (a) enclavesecurity.com and I’d be happy to link to you as well. Here are a couple:

Mandiant Blogs (http://blog.mandiant.com/archives/730)
McAfee (http://www.mcafee.com/us/local_content/reports/how_can_u_tell_v5.pdf) (Old Link Removed)

More to come…

Aurora Malware Hashes and Domains

McAfee has recently released specific details about their analysis of the Aurora malware that was used to compromise 30+ companies over the past few months. This malware is consistent with the types of files that Enclave and other organizations who have responded to APT based attacks have discovered. It appears to utilize many of the same mechanisms and even file name in many such cases. A link to one of their reports on the topic can be found at:

www.mcafee.com/us/local_content/reports/how_can_u_tell_v5.pdf

Specifically the hashes for the Aurora malware are:

securmon.dll: E3798C71D25816611A4CAB031AE3C27A
Rasmon.dll: 0F9C5408335833E72FE73E6166B5A01B
a.exe: CD36A3071A315C3BE6AC3366D80BB59C
b.exe: 9F880AC607CBD7CDFFFA609C5883C708
AppMgmt.dll: 6A89FBE7B0D526E3D97B0DA8418BF851
A0029670.dll: 3A33013A47C5DD8D1B92A4CFDCDA3765
msconfig32.sys: 7A62295F70642FEDF0D5A5637FEB7986
VedioDriver.dll: 467EEF090DEB3517F05A48310FCFD4EE
acelpvc.dll: 4A47404FC21FFF4A1BC492F9CD23139C
wuauclt.exe: 69BAF3C6D3A8D41B789526BA72C79C2D
jucheck.exe: 79ABBA920201031147566F5418E45F34
AdobeUpdateManager.exe: 9A7FCEE7FF6035B141390204613209DA
zf32.dll: EB4ECA9943DA94E09D22134EA20DC602

In addition they have also identified a list of domains that you should be blocking that are used as a part of this malware as well. The following domains have been detected as containing malicious code associated with the Aurora malware:

ftpaccess[dot]cc
google[dot]homeunix[dot]com
tyuqwer[dot]dyndns[dot]org
blogspot[dot]blogsite[dot]org
voanews[dot]ath[dot]cx
360[dot]homeunix[dot]com
ymail[dot]ath[dot]cx
yahoo[dot]8866[dot]org
sl1[dot]homelinux[dot]org
members[dot]linode[dot]com
ftp2[dot]homeunix[dot]com
update[dot]ourhobby[dot]com
filoups[dot]info

Thanks again to the teams at McAfee / Foundstone for releasing this data. These are the types of datasets we need to be better about sharing if we are going to be effective at stopping these directed attacks!