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.

Here is geo-locations of the Ozdok command and control servers based on last few months data:




















6 (not currently active)












The stats above clearly show that these servers are wide spread across the USA.  Only two command server were found to be located outside the USA.  So does it mean that shutting these servers down would result in a complete botnet shut down?  Keeping in view Ozdok's multi layered fallback mechanism the answer here is 'no'. 

Here is Ozdok's command and control structure.

1. A majority of Ozdok variants use domain names to locate their command servers.  Samples seen so far by me had a complete list of domains embedded in the malware body.  In case one domain fails, it will move to the next one.

Bad news:


Shutting down the back end servers will not have a long term effect on this botnet.  If these servers are ever taken down, the bot herders would move their command servers to some other net block.

2. All the new samples have a hard coded list of custom DNS servers.  Each domain in the list will first be resolved through host configured DNS servers.  In case of failure, Ozdok will try to resolve it using a hard coded list of NS servers.  If it still fails, it will move to the second domain in the list and repeat the same process.

More Bad News:


If these domains are taken down with the registrars help, custom DNS severs will come into play for supplying new CnC hosts.

3. In case all the hard coded domains and custom NS servers are taken down.  Ozok will fall-back to its final nefarious trick.  Newer samples are equipped with a domain generation algorithm.  In case all fallback mechanisms fail, Ozdok has the ability to generate one random domain per day.  This domain is generated based on the current date and time.

Even More Bad News:


Unless someone is committed enough to pre-register those domains, the bot herders can always come forward and register those domains and take botnet control back.


                                                       Figure 1


                                                      Figure 2

4. There is one more fallback mechanism which most of modern malware like Ozdok follow now a days, and that is BotnetWeb.  For a refresher here is how I define BotnetWeb.

"A collection of heterogeneous Botnets being operated in
conjunction with each other controlled by one or more closely linked
cyber criminal group(s)"

As a matter of fact, during the past many months I have seen Ozdok being a sub download of many other known malware such as Trojan.Piptea. Historic data shows that most of the time Ozdok is dropped onto pre-infected machines as a spam component together with other malware, each dedicated to a particular job.

Can't be worst than this:


In case all other fallback mechanisms fail there is always a chance that bot herders will move their reserve troops (top level malware) forward and may drop an updated version onto the infected machines pointing to a completely different address space.


Here is the complete list of constant domains (45) with their currently resolved IPs. 'Not Found' means that domain currently is not pointing to any IP address.           <->              <-> Not Found               <-> Not Found               <-> Not Found             <-> Not Found                <-> Not Found             <->         <->              <-> Not Found           <->            <->            <-> Not Found
jabrastatic.inf0            <-> Not Found            <-> Not Found           <-> Not Found             <->           <->             <-> Not Found        <-> Not Found               <-> Not Found                  <->                <-> Not Found                 <-> Not Found               <-> Not Found               <-> Not Found           <-> Not Found                <-> Not Found              <-> Not Found            <-> Not Found          <-> Not Found             <->                <-> Not Found             <-> Not Found           <-> Not Found          <-> Not Found           <->           <-> Not Found                <-> Not Found            <-> Not Found           <-> Not Found             <->            <-> Not Found            <-> Not Found

Live = 13, Dead = 32

Auto generated domains for the last few days look like this:

After seeing all these fallback mechanisms, it doesn't look very easy to kill Ozdok in one go but hurting this beast might not be that difficult.  Sudden shutdown of the current CnC host will cause the bot herders to loose important logistics and valuable data.  This shutdown might also earn infected machines some time to disinfect themselves.  Above all, it will be another gestures to show the bad guys that the security industry is awake and keeping a close eye on them.

Update 1: We just got a response from 'Go daddy' authorities that is actually a forwarding server and is not directly under control of the bot herders. But then why is the ozdok domain,, still pointing to it? This is something which I don't have any explanation for at the moment.

Atif Mushtaq @ FireEye Malware Intelligence Lab

Detailed Question/Comments : research SHIFT-2 fireeye DOT COM

7 thoughts on “Killing the beast…Part 4 (Ozdok)

  1. Maybe I am missing the obvious here but since the malware keeps going looking for the cnc until it finds one, surely the best approach would be to subsitute a benign cnc.
    Even if the malware uses fairly high grade cryptography, I would have thought that having a copy of the source (the malware) and some grunty server farms would be enough to crack it.

  2. Somebody with super hacking powers should prepare self-clean Ozdok “update”, hack into one of CnC servers and put it there, and upload it to as many zombie PCs as possible before herders notice (and then destroy the CnC too).
    That way the PCs itself will get cleaned. (I think erasing whole windows directory and MBR will kill also other possible malware, yet it will give the careless users a chance to recover their data at least)
    I think that would hurt the herders a lot.
    There are just 2 problems:
    1) it’s not legal to delete user files (although IMHO they deserve it) (and I think GOV should cooperate on this)
    2) we need that super hacker hero who’s capable to prepare cleaning “update” in timely fashion + get it into some CnC server.

  3. Im quite suprised that you had GoDaddy help, they are usually blind to help combat spam and abuse, unless that is, your website is critical of a politican

  4. Impressive but can you guys detect and remove the firmware hard drive virus that is infecting pen drives, hard drives, and cd roms. It works both in xp and linux, seems not to cause harm in windows. It is a firmware problem since the drives change disk size and leave space for gahered data.

  5. No Geezer, not that simple because the source only need have the public half of a strong-crypto key pair; finding the private half to bring up your neutered CnC would be quite difficult assuming “high grade crypto”… difficult as in “would take millions of compute-years to crack”…meanwhile black hat can just replace the key more often than that…

  6. I wonder if Microsoft could push out kernel-level IP blocklists to stop this type of thing. I guess bots would just work around it quickly enough though.

Comments are closed.