# Fooled by Andromeda

**0xebfe.net/blog/2013/03/30/fooled-by-andromeda**

0xEBFE

There is a malware with name “Andromeda”, that recently started to spread again.

Let’s listen to the experts from Trend Micro:

[Full blog entry](http://blog.trendmicro.com/trendlabs-security-intelligence/andromeda-botnet-resurfaces/)

Hm, it is strange behavior for mass-spreading malware, isn’t it? Someone should explain
what’s really going on - and this “someone” will be me :)

Andromeda has several anti-debugging or anti-reversing tricks:


-----

It checks the names of processes by comparing CRC32-hashes:

It checks for Sandboxie dll:


-----

It checks 0 -value in registry key
HKLM\SYSTEM\CurrentControlSet\Services\Disk\Enum for “vmwa”, “vbox”,
“qemu”-strings. Obviously, this is an anti-vm trick:

And finally it checks the elapsed time between “rdtsc”-instructions:

Passing all these checks makes Andromeda avoid address 0x00401E8C, where an
ACCESS_VIOLATION exception would occur. If some anti-reversing checks pass, the
payload is loaded at 0x402413.

This is what the Andromeda payload header structure looks like:


-----

payload_header.cpp
```
   #pragma pack(push, 1)
   typedef struct _ANDROMEDA_PAYLOAD
   {
     BYTE rc4Key[16];       // 0x000
     DWORD encryptedSize;     // 0x010
     DWORD unknown;        // 0x014 probably
   CRC32
     DWORD unpackedSize;     // 0x018
     DWORD offsetEntryPoint;   // 0x01C
     DWORD offsetRelocAndImport; // 0x020
     DWORD relocsAndImportSize;  // 0x024
     BYTE encryptedPayload[];   // 0x028
   } ANDROMEDA_PAYLOAD;
   #pragma pack(pop, 1)

```
This is the header of default-payload at 0x402413 address:

Andromeda uses RC4 for decryption and aPLib-library for decompression. I made an
IDAPython script that decrypts the payload and recovers the relocations and imports. My
[script is based on the great kabopan scripts by Ange Albertini.](http://code.google.com/p/kabopan/)

[You can find my script here: https://github.com/0xEBFE/Andromeda-payload](https://github.com/0xEBFE/Andromeda-payload)

I decrypted the payload at 0x402413 and it does several operations:


-----

Copies itself to %ALLUSERSPROFILE%\svchost.exe
Writes itself to “SOFTWARE\Microsoft\Windows\CurrentVersion\Run” registry key as
“SunJavaUpdateSched”.

And also (sorry for the big picture, but you have to see this):


-----

-----

In this screenshot you can see that Andromeda:

Opens port 8000 — ✔ check :)
Runs new instance of “cmd.exe” — ✔ check :)

It does not have any code to process commands from remote computer, but since standard
handles (StdInput and StdOutput) are redirected to socket it’s possible to execute commands
remotely. Obviously it’s a fake payload - someone got fooled :)

Let’s check the SEH-handler of Andromeda:

As you can see Andromeda basically changes execution flow when an exception occurs at the
specified address Andromeda passes the execution flow to the “load_payload”-function
with address 0x00402058 as argument. In this real payload, the malware injects itself to
“msiexec.exe” or “svchost.exe”.

If you check more closely you can spot a third payload that runs in “msiexec.exe” or
“svchost.exe”:


-----

[This payload contains the C&C url. However this url is also a fake, thanks to @aaSSfxxx for](https://twitter.com/aaSSfxxx)
pointing me out.

You might ask the question: “How do cyberterrorists test their cyberweapons if it’s not
possible to run them in Virtual Machines?”. And the answer is:

Andromeda checks the CRC32 of the %SYSTEMDRIVE% volume name, and if equal to
**0x20C7DD84 (for example “CKF81X”), the real payload is executed.**

[Thanks to this great forum for supplying the sample: http://www.kernelmode.info/](http://www.kernelmode.info/)

MD5-hash of analyzed sample: 2C1A7509B389858310FFBC72EE64D501


-----