High Performance Network Security, Enterprise and Data-Center Firewall

High Performance Network Security, Enterprise and Data-Center Firewall

A Good Look at the Andromeda Botnet

by RSS He Xu  |  April 16, 2014  |  Category: Security Research


This article originally appeared in Virus Bulletin


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.


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). - 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_MACHINEsystemcurrentcontrolset servicesdiskenum

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

image image

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

Figure 2: Anti-VM.

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).

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'.

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

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:

Key:HKEY_LOCAL_MACHINESOFTWAREMicrosoftWindows CurrentVersionRun



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: - SEM_FAILCRITICALERRORS - SEM_NOALIGNMENTFAULTEXCEPT - SEM_NOGPFAULTERRORBOX - SEM_NOOPENFILEERRORBOX

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 SettingsTempms<%s>.<%s>

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

HKEY_LOCAL_MACHINEsoftwaremicrosoftwindows nt



%allusersprofile%Local SettingsTempms<%s>.<%s>

The filename's suffix will be one of 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).

In Figures 6 and 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. image

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


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


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.

The first-level structure is simple, as follows:

Struct RecvPack



Char(*) Body;

} *RecvPack;

Figure 8: Example package
Figure 9: After RC4 encryption.
Figure 10: String after base64 encryption.
Figure 11: The real network stream
Figure 12: The received package binary view.
Figure 13: Received package after decryption.

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.

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).

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 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.

Figure 14: Snapshot from the web panel of the Andromeda C&C server showing the various Cmd types ('Task type').
Figure 15: The bot tries to download the module.

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):


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):


Figure 16: Network traffic

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

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

The Modules

At least two more modules have been observed in the network traffic of another variant (see Figure 19). There are three modules in total, as follows:


Figure 17: The EXE is not encrypted.


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

Module file name Underground module name Underground description Price
f.pack Formgrabber Without the injector, http/https, all browsers including Chrome $500
r.pack Ring3 RootKit $300
s.pack Socks4




Figure 19: Two more modules have been observed


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 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 following string: - config 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:

  • facebook.com.+pass=

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 fi nds the following four types of web browser, it will hook the corresponding APIs to grab information:


WINNET.dll HttpSendRequestW









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).


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 fi rewall. 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.

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 fl exible and dynamic. It can enhance its abilities in different fi elds by installing different modules. It can distribute other malware very effi ciently. It uses several RC4 keys to encrypt data for communications with C&C servers to make tracing it much more diffi cult.

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?

by RSS He Xu  |  April 16, 2014  |  Category: Security Research
comments powered by Disqus

FortiGuard Labs on the Web

search results hidden links