Tribal Chicken

Security. Malware Research. Digital Forensics.

Part 2 of Monday Malware analysis #1: Zemot / Rerdom

Update 20141010: Thanks to @herrcore for pointing out I had used the incorrect name for the malware. Name has now been updated.

A few days ago I started looking at running some Malware that was received by my email account via a Phishing email.

Monday Malware analysis: Zemot/Rerdom (Part 1)

By correlating the behaviour and executables with other information I determined that this malware is commonly referred to as Zemot – A dropper which will download and run Rerdom, a binary which will perform click fraud for the Asprox botnet. Lets take a deeper look and try to figure out exactly what the malware is doing.

We’ll take a step back and start with the initial file: Court_Notice_Copy_04-04-14_AP.exe

This is simply the “dropper”. A common technique, especially with phishing, is to send a very lightweight, seemingly unsuspicious file which will then connect out to predetermined servers (There are other methods), download the real payload and “drop” it onto the now-compromised system for execution. This also has the added benefit of limiting the target scope of the malware if required, as the dropper can perform basic checks to determine if it should proceed.

Basically it’s their foot in the door. Once you allow that file to execute, your computer is theirs (and what we like to refer to as a ‘zombie’ – a computer enslaved to a botnet).

This dropper appears to drop files (with random file names) all through the %USER/Appdata folder, as well as add a load of data to the registry. Again, this is fairly common.

Screen Shot 2014-04-10 at 8.24.08 pm

I covered some of this in the first post, but lets take a look at the changes to the system and the network activity the dropper makes, by analysing and stepping through the packet capture.

The first entry of interest is a HTTP POST request to an IP address registered to an Italian ISP, however at the time of writing this second article the IP address is longer online. The response begins to download a binary file but does not seem to complete. I am yet to determine the data that was POST-ed to the server… At first glance it appears to be encrypted.

As I said, according to the packet capture the download never completes. However shortly afterwards a DNS request is made for A HTTP GET request is then made for

A 200 OK is returned but no further action is taken. I take this to be a ‘heartbeat’ or perhaps just checking for a network connection.

The next request is a HTTP GET request and associated DNS lookup for

The response downloads a binary/PE file which analyses as Trojan.Generic – According to the hash, this is the update_flashplayer_[characters].exe that we saw in the first article. Unfortunately when extracting the file from the packet capture and attempting to run on a clean VM it failed to execute properly or do anything.

It appears that after executing this file the system reboots. I am yet to test if this is a intentional or simply a coincidence.

Once the system comes back up it reaches out to again but this time downloads the file /p59.12/soft64.dll which spawns and hooks into an svchost.exe process. I imagine the executable responsible for downloading the DLL contains the logic to load it into memory.

The malware also makes periodic connections to some services in this form:

To the “eve” request, the server will respond with a simple ‘hi!’ – This could be checking connectivity to certain areas or simply just phoning home. However there are several forms of this:

  • GET /b/eve/[string]
  • POST /b/req/[string]
  • POST /b/opt/[string]
  • GET /b/letr/[string]
  • GET /b/pkg/[string]

The *eve *request responds with ‘hi!’, the other responses are either encrypted or do not respond with data (Respond with 404 Not Found, 403 Forbidden or 500 Internal Server Error).

The next major event is actually where I noticed we were hitting out to server located in Perth – whether this is simply coincidence or if the authors of the malware went to the trouble to add geolocation to the software, I can only speculate. (As I side note, there are other addresses that I see a similar communication with).

Anyway, we make an encrypted POST request to the server and what I find interesting is that the response is actually a 476K encrypted response. So far though have been unable to carve anything of interest out of the response:

Further analysis of this will definitely be required, so when (or if) I find anything of interest I will write another article about it, however it may be that this is a module of the malware to perform a certain function, or perhaps configuration data.

This is where the actual work of the malware becomes apparent.

We make DNS lookup requests for a bunch of domains all related to search:

These appear to change periodically, possibly every day. For example, at the time of writing this article, looking at the older packet capture the above addresses no longer worked, but we were hitting these:

The domains all take the form [something] and are registered via the registrar OnlineNic to the company “Investments Limited Gyreklas”, according to the whois data (Which can be taken with a grain of salt – Note this is almost guaranteed to be fake) registered in Nicosia, Cyprus.

The search pages have the same template and after making a few standard HTTP requests out to all these search pages, we start to see lots of requests to legitimate advertising providers (Google, for example), as well as a lot of requests to “click” related URL’s most of which, upon verification, do not appear to be legitimate.

Screen Shot 2014-04-10 at 8.41.33 pm

This will continue constantly whilst the system is powered on and connected to the internet.

Once the initial infection / payload has been delivered, a lot of HTTP traffic from the infected computer is generated, thus we can reasonably assert that this particular malware is designed for, or at least currently assigned to carry out, ad fraud (As part of a botnet).

Other domains I have seen this malware hit for C&C or downloads are:


Most whois info shows Russia, some US.

Domains / IP Addresses analysed on 07/04/2014 which appear to be part of the Command & Control (C&C) infrastructure:

  • (round-robin DNS)

Domains / IP Addresses analysed on 07/04/2014 which appear to be used only for payload delivery:


Other suspicious domains / IP Addresses observed during packet capture:


One other interesting point I noticed is that every server contact via HTTP for C&C or other requests, was running the nginx web server on either port 443 (though non-SSL) or port 8080.

I would hazard a guess that this could be due to it being a nice, lightweight piece of software they can easily deploy their software behind rather than any other reason. But interesting none the less.


I can conclude that this is a common form of the Asprox botnet malware, in this case assigned to performa ad fraud, where the infected (zombie) computers will generate traffic, impressions and false clicks on ads amongst other things in order to generate the botnet operators some money.

The delivery mechanism seems to work as such:

  1. User executes infected executable
  2. Executable runs and downloads the actual Asprox malware (or updates)
  3. Asprox spawns and injects itself into svchost.exe, as well as enabling persistence by running on startup.
  4. Contacts Command & Control servers to receive instructions
  5. Downloads a package (encrypted)
  6. Carries out instructions from C&C servers.

Asprox has typically been known to carry out bulk email transmission, FakeAV as well as being a dropper for the rather nasty ZeroAccess / Siref rootkit. You may find these links interesting:

So there you have it, a high level overview of what Kulouz / Asprox does when performing ad fraud. While perhaps not a comprehensive, disassembly and forensic analysis of the malware it shows you how these sorts of malware behave.