0 Results Found
            Back To Results
              Threat Analysis

              Ozdok/Mega-D Trojan Analysis

              • Author: Joe Stewart
              • Date: 11 February 2008

              Last week the TRACE research team at Marshal put forth some statistics regarding spam activity from botnets. The statistics pointed to a botnet dubbed "Mega-D" as the new leader of the spambot pack, spewing 32% of the world's spam according to Marshal's spamtraps. This set off a firestorm of speculation: what family of malware was behind this previously unknown botnet? How had it emerged to challenge Storm with hardly a mention in any research articles or press?

              Based on spam samples provided by Marshal, we looked for unique patterns in the message headers, and began to filter traffic across our own monitored customer base to reveal source IPs trying to send spam to our clients. Based on the number of bots connecting to mail servers we monitor, we estimate that Mega-D consists of around 35,000 infected machines worldwide. This is a very strong botnet, but hardly a challenger to Storm. Even though Storm has waned to around 85,000 bots, it still holds far more spamming capacity. Why the Storm spam seen by Marshal's spamtraps has fallen off, we can only speculate - more on that below.

              A sample of a typical spam email sent by Mega-D is shown here:


              After locating and tracking a large number of infected IP addresses attempting to send spam to our clients, we were able to pinpoint the botnet command and control servers along with the malware responsible for the Mega-D spam. As it turns out, Mega-D is composed of bots from a little-known malware family called "Ozdok".

              Despite most AV vendors having detection for the Mega-D bot we analyzed, only one of them recognize it as being part of the Ozdok family. Most give it generic catch-all names like "Pakes" or "Agent", which might be part of the reason why Ozdok was able to slip under the radar for over a year as it slowly built up a formidable botnet.

              Some sample Ozdok filenames are icf.exe, icf32.exe, cacglivn.exe, guyymgvl.exe and mm27nov.exe. The (phony) embedded file description is "Microsoft Internet Countermeasures Framework". The older variants usually install themselves to %windows%\system32\svchost.exe:exe.exe or a similarly named alternate data stream (ADS). These streams are hidden from normal listing in Explorer or a command shell. Startup at boottime is facilitated by the addition of a system service labeled "ICF". Additionally, the system firewall settings are modified to add svchost.exe as an authorized application. mm27nov.exe does not appear to contain code to set up persistence across reboots, so it may simply be an update intended to be executed by an existing instance of Ozdok.

              When run, Ozdok will start an instance of svchost.exe and inject its code into that process. It attempts to resolve one of the following domain names in order to connect to the botnet command-and-control:

              • uikkl.info
              • rixosspa.info
              • micralokp.biz
              • yankdream.info
              • blagoinc.info
              • aaauaa.info

              Commands and data are sent over port 80 to these servers, but the traffic is not HTTP (or even SSL) - the communication is encrypted using a non-standard algorithm. Because of this, bots behind an HTTP proxy will likely be unable to establish contact with the command and control server.

              After checking in with the controller on port 80, Ozdok will attempt to send a test message to port 25 on one of the controller hosts. If it is successful, it will download (using the encrypted protocol over port 80) a spam template and begin sending spam to a list of email addresses obtained from the server. The template is cached for efficiency. Typically the spam seen so far has contained advertisements for VPXL (a male enhancement product) and designer replicas.

              Strings in the Ozdok executable indicate that Ozdok is aware of mail servers employing greylisting as a means to combat spam, and is able to retry messages after a timeout in order to defeat these protections. Additionally, Ozdok attempts to pattern-match error messages from SMTP servers (in multiple languages); in order to determine the end result status of messages it attempts to send. As a result, it may be effective in helping the bot owner maintain a clean list of email addresses by culling addresses that respond with "no such user" and similar error messages, while keeping addresses that were simply rejected because a particular mail passed a spam score threshold.

              At the same time, this causes a problem for companies/individuals who use spamtrap email addresses to monitor spam - if for some reason the spamtrap email bounces (for instance, because another researcher is sinkholing the spam but bouncing random messages in order to keep their bot from standing out with its 100% delivery rate) the spamtrap will be removed from the botnet's mailing list and it will appear to the monitoring party as though spam from the botnet has dropped off. Perhaps this could account for the drop-off in Marshal's Storm emails, but we are only speculating here.

              The breakdown of Ozdok/Mega-D bots worldwide is as follows:


              Based on public reports from owners of infected machines, it appears that Ozdok is installed via web exploits, but the exact vector is unknown. With many trojan authors increasingly relying on "pay-per-install" exploit services, it is getting more difficult these days to determine just where the malware is coming from, as it may be a time or quantity-limited rollout depending on the terms of the exploit service.

              The one thing Ozdok shows is just how easy it is to roll-your-own spam botnet. There's really nothing terribly complex about downloading a template and sending SMTP commands. A no-frills spambot can be coded in a very short time, and as long as it doesn't draw too much attention to itself, it can enjoy a fairly long run on a single set of controller IPs. The time spent writing extras like P2P control protocols seem pretty much wasted when a botnet like Ozdok/Mega-D can run for over 6 months without having to change controller IP addresses.

              SecureWorks would like to thank Team Cymru and myNetWatchman for their assistance in analyzing this trojan.

              Related Content