A good look at the Andromeda botnet


He Xu

Fortinet, Canada
Editor: Helen Martin


The Andromeda bot is flexible and dynamic. Its modular structure allows it to enhance its abilities in different fields simply by installing different modules. He Xu takes a close look at the Andromeda botnet.

Andromeda is a modular bot. The original bot simply consists of a loader, which downloads modules and updates from its C&C server during execution. The loader has both anti VM and anti-debug features. It will inject into trusted processes to hide itself and then delete the original bot. The bot hibernates for a long time (from several days to months) between communications with its C&C server. As a result, it can be difficult to obtain information about network traffic between the infected system and the C&C.

The latest official build version of the Andromeda bot is 2.06. This version has some new content in the sending package from the bot itself. In addition, it is capable of distributing various other botnet variants, as well as downloading modules and updates.

GeoIP map showing the distribution of Andromeda.

Figure 1. GeoIP map showing the distribution of Andromeda.

The packer

The packer contains a lot of redundant code, so the real code can be hidden amongst it. It calls the GetModuleHandleA API to get the base address of the bot, examines the MZ tag and PE signature, and then checks if the number of sections is six. If there are six sections, the packer will first load the data from the fourth section and try to decrypt it. It then verifies the decrypted MZ tag and PE signature and calls the CreateProcessW API to reload the original bot, but with the dwCreationFlags value set to CREATE_SUSPENDED. The packer will inject the second process with different code, which is from the decrypted fourth section. After that, the packer will try to load another PE signature from the fifth section using the same method as above.

This powerful packer can embed and execute two different pieces of malware at the same time. However, the data in the fourth section is not currently in PE format after decryption, meaning that the packer can only carry the Andromeda bot.

The loader

The loader starts by getting the base address of ntdll.dll from the TEB structure. It uses this address as a parameter to get ntdll export APIs and to increase the complexity of analysis. There is no clear string of API names, only checksum values to identify the different APIs. The following is a list of the checksums and their corresponding API names:


Next, the loader checks for the mutex ‘lol’ by calling the OpenMutexA API to determine whether it should skip the anti VM and anti-debug routines.

If no mutex is found, the bot will try to check whether it is being executed within a virtual machine or debugger:

  1. It enumerates the current process list, converts every process name to lower case, then calculates the checksum and compares it with an embedded checksum list which represents a virtual machine environment (Figure 2).


    Figure 2. Anti-VM.

  2. It tries to call the GetModuleHandleA API to load sbiedll.dll to check for the Sandboxie VM.

  3. It queries the following registry entry to get the disk name string (see Figure 3):

    key: HKEY_LOCAL_MACHINE\system\currentcontrolset\services\disk\enum
    valuename: 0
    Querying the registry to get the disk name string.

    Figure 3. Querying the registry to get the disk name string.

    It skips the first eight bytes, then examines the next four bytes (Figure 4).

    Eight bytes are skipped, then the next four are examined.

    Figure 4. Eight bytes are skipped, then the next four are examined.

    The current loader detected three VMs, as shown in Figure 4.

  4. It calls rdtsc twice to calculate the difference in the return value. A result larger than 200h indicates that debugging is in progress (Figure 5).

    rdtsc is called twice to calculate the difference in the return value.

    Figure 5. rdtsc is called twice to calculate the difference in the return value.

If the bot loader detects any type of abnormal condition, unlike other botnets which will exit directly, the Andromeda bot will continue to run a tiny piece of code that I refer to as ‘passive code’. Otherwise, the bot will run the main code to communicate with the C&C server.

Passive code

This tiny piece of simple code copies itself as svchost.exe into the folder%ALLUSERSPROFILE%, then adds itself to the registry as follows:


It will open local port 8000 to sniff. Once it receives a remote command, it will run cmd.exe to receive and execute it.

Main code injection

It calls the SetEnvironmentVariableW API to save the original bot’s full path to the environment variable src.

It then calls the ZwQueryInformationProcess API to check whether the system version is 64-bit or 32-bit. If it is running under a 32-bit OS, the bot will inject wuauclt.exe; if it is running under a 64-bit OS, it will inject svchost.exe. (Our example is running under a 32 bit OS.)

After that, the bot will create a new process, wuauclt.exe, with dwCreationFlags set to CREATE_SUSPENDED. It then injects wuauclt.exe by calling various MAP APIs. It will modify the entry point code of wuauclt.exe to the following:

push <address of injected code>

Finally, the bot calls the ZwResumeThread API to activate the injected process wuauclt.exe, and then exits directly.

Main code local initialize environment

In the injected code, all information is clear to see. There are no more encrypted strings or blocks. The bot calls the SetErrorMode API to disable most error notice windows.

The parameter is 0x8007, which means the following:





The bot calls the GetEnvironmentVariableW API to get the original bot’s full path using the environment variable src, then resets that variable by calling the SetEnvironmentVariableW API with a null string parameter.

It will check the security identifier of the current process (wuauclt.exe) to see whether it belongs to an administrator, then sets up the replication destination and registry key. After this it uses the current tick count value to determine the suffix of the replicated filename.

The bot may copy itself to one of two destinations:

If the current running user is an administrator, the tag ‘ar’ will be set to 1. The bot will set up the registry as follows:

%allusersprofile%\Local Settings\Temp\ms<%s>.<%s>

Otherwise, the tag ‘ar’ will be set to 0 and the registry will be set up as follows:

HKEY_LOCAL_MACHINE\software\microsoft\windows nt\currentversion\windows
%userprofile%\Local Settings\Temp\ms<%s>.<%s>

The filename’s suffix will be one of the following, depending on the value of the current tick count: exe, com, scr, pif, cmd or bat.

The bot will try to create another mutex with a string generated from the system volume information. If it already exists, it will delete the original bot sample and then exit directly. Otherwise, the bot will copy itself to the generated destination and add itself to the registry so that it will run automatically at the next system start up.

Finally, the bot will create two new threads for executing previously saved modules and DLLs from the registry (Figure 6). Of course, they are encrypted with the RC4 algorithm and with a fake ZIP header (Figure 7).

Two new threads are created for executing previously saved modules and DLLs from the registry.

Figure 6. Two new threads are created for executing previously saved modules and DLLs from the registry.

The threads are encrypted with RC4 and with a fake ZIP header.

Figure 7. The threads are encrypted with RC4 and with a fake ZIP header.

In Figure 6 and Figure 7, the value name of the registry is generated from the CRC32 value in the fake Zip header. Now that the local initialize operation has finished, the bot will prepare for network operation with the C&C server.

Initial network operation

The bot will create a new thread recurrently, each time taking at least 23C34600h ms – which means more than six days each time. As a result, monitoring the network traffic over a short period may not be sufficient to detect the presence of Andromeda.

The pattern of the first sending package is as follows:

  • The id value is generated from the local system volume information.

  • The bid value is hard coded in the bot and may refer to the build id.

  • The bv value is hard-coded in the bot and may mean build version (currently this is 206h (518)).

  • The sv value refers to the victim system version.

  • The pa value is the return value of the call to the ZwQueryInformationProcess API to identify the OS as 32-bit or 64-bit.

  • The la value is generated from the IP address of www.update.microsoft.com.

  • The ar value is the return value of the call to the CheckTokenMembership API to identify whether the bot is running under an administrator account.

The pa and ar data are new in this version of Andromeda.

An example is shown in Figure 8. Figure 9 shows the same example after RC4 encryption, and Figure 10 shows the string after base64 encryption. Finally, Figure 11 shows the real network stream, and Figure 12 shows a binary view of the received package.

Example package.

Figure 8. Example package.

After RC4 encryption.

Figure 9. After RC4 encryption.

String after base64 encryption.

Figure 10. String after base64 encryption.

The real network stream.

Figure 11. The real network stream.

(Click here to see a larger version of Figure 11.)

The received package binary view.

Figure 12. The received package binary view.

The first-level structure is simple, as follows:

Struct RecvPack
     INT CRC32;
     Char(*) Body;
} *RecvPack;

The C&C server does not use the same RC4 key to encrypt the reply package, but uses the id value as the RC4 key, whose length is only 4. So without the sending package information, we cannot decrypt the received package.

The received package after decryption is shown in Figure 13.

Received package after decryption.

Figure 13. Received package after decryption.

The structure is as follows:

First, let’s look at the meaning of the Cmd type (‘Task type’) according to a snapshot from the web panel of the Andromeda C&C server (Figure 14).

Snapshot from the web panel of the Andromeda C&C server showing the various Cmd types (‘Task type’).

Figure 14. Snapshot from the web panel of the Andromeda C&C server showing the various Cmd types (‘Task type’).

There will be several blocks in the received package (there are two blocks in Figure 13).

In Figure 13, the first block’s Cmd type is 2, which means ‘install plug in’. The bot will try to download the module, as shown in Figure 15.

The bot tries to download the module.

Figure 15. The bot tries to download the module.

(Click here to see a larger version of Figure 15.)

The module starts with a fake Zip header whose size is 0x10. We have seen an example of this before, which was saved in the registry (Figure 7) – they are the same.

The bot will save the module into the registry after executing it. Then the bot will give feedback to the C&C server with the following pattern:


A real example is as follows:


The id is the same as in the sending package.

The tid is from block offset 04, 106 is equal to 6Ah.

The result will be 1 if execution of the module is successful, otherwise it is 0.

Figure 16 shows the network traffic.

Network traffic.

Figure 16. Network traffic.

The other block’s Cmd type is 1, which means ‘download EXE’ for spreading other malware.

The bot will try to download and drop the EXE as a temp file for execution. The EXE is not encrypted like the module (Figure 17):

The EXE is not encrypted.

Figure 17. The EXE is not encrypted.

The bot will communicate with the C&C server after execution.

The bot communicates with the C&C server.

Figure 18. The bot communicates with the C&C server.

The modules

We have seen one module with the name ‘r.pack’. What does it do during execution? Are other types of module installed?

At least two more modules have been observed in the network traffic of another variant (see Figure 19).

Two more modules have been observed.

Figure 19. Two more modules have been observed.

There are three modules in total, as follows:


The r.pack module is a ring3 rootkit. It will inject all running processes, then hook the following APIs to hide the bot itself:

  • ZwResumeThread

  • ZwQueryDirectoryFile

  • ZwEnumerateValueKey.


The f.pack module is a form grabber. It will create a new thread to initialize and monitor a named pipe. Once data enters the pipe, the thread will parse it and communicate with the C&C server via a different URL link (Figure 20).

The thread communicates with the C&C server.

Figure 20. The thread communicates with the C&C server.

The thread will replace the default C&C server gate image.php with fg.php, and then add a parameter id, which is the same as in the first sending package.

The content of the sending package is also base64 encrypted (as in the previous sending package). After decryption, the data should be the following string:


The C&C server will reply with the pattern data – the algorithm is the same as in the previously received package, but in this case the related RC4 key is not taken from the id, instead the same RC4 key is used as was used by the sending package.

The pattern after decryption is:


Next, it injects all running processes, just like r.pack, and hooks the ZwResumeThread API. After that it will check the process name. Once it finds the following four types of web browser, it will hook the corresponding APIs to grab information:

All the data blocks beginning with the string POST will be checked and sent to the named pipe if they meet all the conditions.

The thread that was mentioned before for monitoring the same named pipe will continue to verify the grabbed data according to the pattern and send it to the C&C server.


The s.pack module acts as a local proxy, it has an export function, Report, that can show its information (Figure 21).

Export function Report.

Figure 21. Export function Report.

This module will open local port 0438h (1080) and wait for a remote connection – as such, it will be useless if the compromised system is behind a firewall. The forward destination IP and port are in the received package.

Another special variant

One more example of a received package from another variant of Andromeda is shown in Figure 22.

Received package after decryption.

Figure 22. Received package after decryption.

We can see that there is no Cmd type 2, only Cmd type 1 for ‘install EXE’ and Cmd type 3 for ‘update bot’. So, in this case the bot is only used to distribute other malware (e.g. ZeroAccess, Kelihos, FakeAV, etc.).


We have seen some changes in the Andromeda bot. It is very flexible and dynamic. It can enhance its abilities in different fields by installing different modules. It can distribute other malware very efficiently. It uses several RC4 keys to encrypt data for communications with C&C servers to make tracing it much more difficult.

Furthermore, different botnets have combined forces to spread themselves, so infected machines and victims are exposed to greater risks and damage. This has created a very serious problem for detecting and cleaning infected machines effectively.

The cat-and-mouse game is certainly ongoing. The mouse is becoming much smarter and more dynamic, but what about the cat?


[2] ZwQueryInformationProcess function. http://msdn.microsoft.com/library/windows/desktop/ms687420.

[5] Well-known security identifiers in Windows operating systems. http://support.microsoft.com/kb/243330.

[6] Inside Andromeda Bot v2.06 Webpanel / AKA Gamarue – Botnet Control Panel. http://malware.dontneedcoffee.com/2012/07/inside-andromeda-bot-v206-webpanel-aka.html.



Latest articles:

Cryptojacking on the fly: TeamTNT using NVIDIA drivers to mine cryptocurrency

TeamTNT is known for attacking insecure and vulnerable Kubernetes deployments in order to infiltrate organizations’ dedicated environments and transform them into attack launchpads. In this article Aditya Sood presents a new module introduced by…

Collector-stealer: a Russian origin credential and information extractor

Collector-stealer, a piece of malware of Russian origin, is heavily used on the Internet to exfiltrate sensitive data from end-user systems and store it in its C&C panels. In this article, researchers Aditya K Sood and Rohit Chaturvedi present a 360…

Fighting Fire with Fire

In 1989, Joe Wells encountered his first virus: Jerusalem. He disassembled the virus, and from that moment onward, was intrigued by the properties of these small pieces of self-replicating code. Joe Wells was an expert on computer viruses, was partly…

Run your malicious VBA macros anywhere!

Kurt Natvig wanted to understand whether it’s possible to recompile VBA macros to another language, which could then easily be ‘run’ on any gateway, thus revealing a sample’s true nature in a safe manner. In this article he explains how he recompiled…

Dissecting the design and vulnerabilities in AZORult C&C panels

Aditya K Sood looks at the command-and-control (C&C) design of the AZORult malware, discussing his team's findings related to the C&C design and some security issues they identified during the research.

Bulletin Archive

We have placed cookies on your device in order to improve the functionality of this site, as outlined in our cookies policy. However, you may delete and block all cookies from this site and your use of the site will be unaffected. By continuing to browse this site, you are agreeing to Virus Bulletin's use of data as outlined in our privacy policy.