On November 22, 2011 the Internet Storm Center put out a great blog on Blackhole and Zeroaccess detailing changes in delivery method and payload. Being an incident responder, I find this information extremely valuable, but in this case, I knew something was going on before anything was even published due to our in-house tools and analysis. I mention this not to knock the ISC, but instead highlight what is possible when analysts develop their own tools. This post will focus on BlackHole compromises and how our custom tools and analysis aid us in identifying potential new trends and payloads.
Building on what you know
Before I dive into the specific BH incident we faced these past few weeks, it is worth mentioning that tools for analysis need the ability to persist data to be useful. In our case, we have the ability to store specific “incidents” that occurred on the network. That is to say, we store as much information as we can about a compromise in a database that we can query later.
BH is no stranger to our environment and has hit very hard in the past with a very high success rate. Given that BH is an exploit kit, it is often implemented with little or no change therefore giving us incident responders a way to identify BH vs. other malware families. One of the main compromise details we store and search on is the “verification” which usually consists of the web request associated with the malware. Below is a search for the word “games”, a directory often seen with BH hosts.
Normally, successful compromises are not unusual, but these attacks were bypassing all our standard controls and protections. In the past we observed that with a high attack success rate, changes were likely made to the attacker codebase. Knowing this, we extracted all the addresses being used by the attackers and blocked them as quickly as possible through OpenDNS.
Over the weekend I sent an email to other analysts on the team advising them to keep an eye out for BH and to try and capture any files being dropped. Unfortunately, the PDF files we captured would not render properly in adobe Reader and therefore produced no success exploit. On the other hand, an EXE captured did successfully run, but just appeared to install FakeAV. In retrospect, after viewing the ISC post, there is a chance that ZeroAccess was also installed along with FakeAV, but more analysis would need to be done to determine this.
This week brought new attackers and a few successful attacks, but because we were tipped off the week prior, we were prepared to handle these incidents much faster. On Tuesday I saw the ISC post explaining new payloads and techniques being used by BH and this just confirmed all the things we saw. While our team was not able to pinpoint what changed or why these attacks were all of a sudden successful, we were able to identify that something was out of place allowing us to stop the infections almost instantly.
In my opinion tools will never replace good analysts, but that should never really be the case anyway. Tools should be built to aid the analyst, not replace or hinder them. IDS products do a great job filtering out some of the high-level attacks, but often fail to really make a difference due to a lack of context on the request and a lack of features directly useful to an analyst. Having used several products, I often wonder if the teams building these tools actually do incident response and use them on a daily basis. The tool we built is not perfect, but it allows us to identify patterns like the one discussed above and turn intelligence into actionable items. In due time our system will improve, our analysts will get better and we will become more secure.