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

Figure 1. GeoIP map showing the distribution of Andromeda.

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

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.

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_MACHINE\SOFTWARE\Microsoft\Windows\CurrentVersion\Run
ValueName:SunJavaUpdateSched
Data:%ALLUSERSPROFILE%\\svchost.exe

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

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

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

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:

HKEY_LOCAL_MACHINE\software\microsoft\windows\currentversion\Policies\Explorer\Run
<%lu>
%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
Load
%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).

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.

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.

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:

id:%lu|bid:%lu|bv:%lu|sv:%lu|pa:%lu|la:%lu|ar:%lu

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.

Figure 8. Example package.

Figure 9. After RC4 encryption.

Figure 10. String after base64 encryption.

Figure 11. The real network stream.

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

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.

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

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.

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:

id:%lu|tid:%lu|result:%lu

A real example is as follows:

id:150233784|tid:106|result:1

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 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 17. The EXE is not encrypted.

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

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

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

Figure 19. Two more modules have been observed.

There are three modules in total, as follows:

f.pack

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

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:

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

s.pack

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

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.

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

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?