FireEye Malware Intelligence Lab

Man in the Browser

Man in the Browser a.k.a MITB is a new breed of attacks whose primary objective is to spy on browser sessions (mostly banking) and in that process intercept and modify the web page contents transparently in the background. In a classic MITB attack, It's a very likely that what the user is seeing on his/her browser window is not something which the actual server sent. Similarly, what server sees on the other end might not be what user was intending to send. Why MITB? How different is it from conventional browser hijacking? I'll explain that shortly.

Infiltrating Pushdo -- Part 1

It's very rare as a researcher to get a chance to explore the inner workings of a botnet command and control (CnC) server. Detailed analysis of a botnet CnC server or command sub-component can yield valuable information about the capabilities of the botnet itself, and possibly the motives of the bad guys behind it. However, gaining access to a botnet CnC server often depends on the will of the hosting providers. Recently, while I was casually monitoring our MAX Network logs for the current geo-locations of Pushdo CnCs, I got the following results for the past 30 days:

PDF Obfuscation using getAnnots()

Since around October 2009, Neosploit¹, a black-market exploit toolkit, has been fabricating PDF files in a slightly new way, but in a way which is difficult for many parsers to analyze for maliciousness. In summary, all of the metadata in a PDF is accessible from the Acrobat Javascript environment. And this metadata is being used for obscuring embedded Javascript code. A PDF parser would need to fill in all the document objects with the correct data, and evaluate the Javascript to find the exploit. (Needless to say, many PDF signature parsers don't do this.) These malicious PDFs ultimately install Mebroot (aka: Sinowal)².

[And, oh yeah, our product detects this.]

Breaking News

Update: There's another exploit toolkit doing similar metadata tricks to obscure a CVE-2009-4324 attack. (That's the most recent 0-day.)

Checking In With The Ozdok Sinkhole

If you’ve read our last couple blogs, you know that FireEye recently hijacked the Ozdok/Mega-D botnet.  Smashing the Mega-d/Ozdok botnet in 24 hours   We registered some C&C backup domains and worked with registrars and hosting providers to have the primary domains and systems taken down.   We directed the Ozdok bots to a sinkhole and watched the connections come pouring in.   After about 5 days we saw 487,430 unique IP addresses connecting to us.   It’s difficult to estimate the true size of this botnet using this number, but we can get a good idea of where the infected systems are.

Brazil is the number 1 infected country with 11.5% of the total infections, followed closely by India and Viet Nam.  China came in at number 16 followed by the USA at 17, each with 1.6% of the total infections we saw.  There were 214 countries represented, but after the top 3, total infections rapidly decreased. 

 

So how big is this thing?  Due to dynamic addressing, one infected system will have many real and advertized IP addresses over time.   When researchers at UCSB hijacked the Torpig botnet, they were able to find a unique bot identifier in the communication to their sinkhole. 

Your Botnet is My Botnet: Analysis of a Botnet Takeover

Smashing the Mega-d/Ozdok botnet in 24 hours

In my previous article, I talked about the Ozdok command and control architecture and its fallback mechanisms in great detail. That article was an attempt to highlight different approaches to take down this botnet theoretically. But when it comes to the actual shutdown, it's far more complex than just finding out the command and control server coordinates and fallback mechanisms. An actual shut down attempt requires someone to take the initiative and start a combined effort involving third parties like ISPs, registries, registrars, etc. 

Instead of playing a passive role, this time FireEye decided to come forward and start working with these groups to make this happen.  The good news is that at the time of writing this article, all the major Ozdok command and control servers (as mentioned in my last post) have been taken down.  As it turns out, no matter how many fallback mechanisms are in place, if they aren't all implemented properly, the botnet is vulnerable.

Killing the beast...Part 4 (Ozdok)

Note: Updates are available at the bottom of this article.

Ozdok a.k.a Mega-d is one of those botnets that has been very successful flying under the radar over the past few years. Recent stats by Marshal TRACE show Ozdok is currently responsible for about 4.2% of the world's overall SPAM.  The question that arises again is who are the guys controlling this botnet, and more importantly from where?  I recently conducted a detailed study of Ozdok's active command and control servers.  There are two main things I took away from this study.

1. The USA is still a first choice for bad guys when it comes to hosting CnC servers.

2. After the McColo experience, these guys are no longer relying on a single net block for hosting their CnCs.  To further ensure their safety, most botnets today are equipped with a fallback mechanism.  As a matter of fact, in the case of Ozdok, there is more than one fallback mechanism involved.  These come into play once the primary command and control structures fall apart.  How?  I'll explain that shortly.

A little more on Donbot...

Donbot is primarily a spam bot, one of the few spam botnets whose growth was not hampered by the McColo shutdown earlier this year.  As a matter of fact, the sudden shut down of big spammers like Srizbi and Rustock helped Donbot climb the spam botnet rankings.  In this article I am going discuss different aspects of Donbot, first as a malware and then in the later half I will try to shed some light on its command and control architecture.

Lets start with a particular donbot sample (273a07dccdfff421bfde652912f02e32).  Like its peer botnets (Ozdok, Xarvester etc), Donbot is also a template based spam bot.  Everything from the subject line to the mailing list, the message body, and the User Agents to be used in the SMTP headers are retrieved from the CnC server. 

Gumblar... Not Gumby!

Ok, I admit this blog post is not about our childhood TV friend, Gumby... Instead it's about a much more sinister character, Gumblar & its malware henchmen...

Originally making its debut back in March/April of this year (see here , here  and here) and then suddenly it went quiet for a few months, until recently... Yes, Gumblar is back with a vengeance & still causing problems for it's unsuspecting victims.

The primary delivery mechanism is still via Drive-By-Download (notably compromised sites serving malicious Adobe PDF's) which when successful will load the malware onto your system.

We have taken a look at a couple of the Gumblar associated malware samples, you can see some VirusTotal results here & here.

A leap into the unknown - Part 1

A leap into the unknown is a series which will discuss some lesser known malware, that has a reasonably good command and control structure.  Most of this malware might not be totally new to the AVs, but they were never considered for more than just creating a signature.  Little or no effort has been made to disclose the motivation behind creating this malware, the CnC architecture, or the people behind it.  These articles are not to prove that "My (discovered) botnet is bigger than yours".  No offense to those who may already know about this malware and might not agree with the word 'unknown' in the title of this article. There is always someone who knows more than you do.

Killing the beast...Part 3

In the third part of this series, I'm going to discuss the command and control structure of another famous botnet, Clampi a.k.a ilomo. Clampi is all about data stealing and is famous for its anti-reversing and evasion techniques. The financial damage this information stealer can cause is evident from the fact that it has recently been publicly disclosed of a cyber theft of more than $150,000.  Notorious isn't it..?

Like the first two parts where I discussed the command and control structure of the Pushdo and Koobface botnets, I'll start by showing the current geographical distribution of Clampi CnCs, followed by a brief analysis on the chances of shutting down these control servers and hence the complete botnet.