Gamarue/Andromeda Comeback

Gamarue/Andromeda botnet was discovered in 2011 and was at its peak in 2013 as a worm propagating in the network using autorun mechanisms. It seems that there has been a recent rise in its infections (Reference: https://blog.avast.com/andromeda-under-the-microscope) . The attack vector is still widely USB infection, using lnk shortcuts to drop and run malicious dll files from temp folder, which in turns drops a file ms[***].exe (itself) in the hidden programdata folder and create persistence to run this payload in programdata folder. The samples I am analyzing are mainly dll files with format like _-_-__---_{Some CLSID format}, which are dropped into temp folders with a .tmp extension and executed using rundll32.exe. 

The dll is packed with a custom packer, which unpacks multiple times and decrypt multiple times in memory, self-modify its code at runtime and finally creates msiexec.exe process in suspend mode and injects the final payload in this process and then calls ResumeThread to run the suspended msiexec.exe. The code uses a lot of low-level APIs which are normally not used and could be used to bypass detection by AV or sandboxing technologies.

The multiple samples I am working with, range from 70MB to 100MB in terms of size most probably to evade AV or buy enough time to execute itself and the main payload. Contains a lot of junk code, random strings, obfuscated code, unconventional code flows, RETN being used as calls or JMPs to the code sections created in memory. 

there seems ti be a generator available to generate Gamarue binaries:

Detection:    

The sample communicates with malicious domains in Russia like disorderstatus(dot)ru and expirepages-kiae-1(dot)nic(dot)ru.

The expirepages domain resolve to 109.70.26.37. Some OSCTI on the ip and domain:

Linked to Locky ransomware

Identified as Command and Control server for botnet by IBM-Xforce 

Related to Angler EK, Ursnif C2 and Android Malware pulses from AlienVault:

Angler EK traffic

Doing a timeline analysis showed the USB events

We can see that the USB (F: Drive) and the dll under a folder named with a single special character:

One of the sample lying undetected was discovered by Microsoft Safety Scanner as Gamarue Worm:

We can see the dropped file in programdata:

I was also able to find the persistence mechanism from the logs of MSS AV, where the malware has written to:

ntrunkey://HKCU@S-1-5-21-2635117884-509320886-844527511-1004\SOFTWARE\MICROSOFT\WINDOWS NT\CURRENTVERSION\WINDOWS\\LOAD:C:\ProgramData\mszor.exe

From above you can infer which user was logged on when the infection was in progress: 

All 3 samples I am working on had common junk strings and fileinfo, which can help to create YARA rules:

 Two of the samples:

After a bunch of junk calls the last one continues with the malicious flow

We can see here a typical way a JMP takes place in the sample:

A lot of junk code with random strings, which can be used to create YARA ruleS:

RETN is used to JMP to locations

VirtualAlloc called by using RETN:

RWE memory allocation:

Jump to decrypted code in memory:

Another memory location allocated:

Third memory allocation and jump:

We see PEB FS[0x30] being accessed.

Failed attempts to load a lot of weird dlls:

 Fourth VirtualAlloc:

Fifth VirtualAlloc:

A binary getting unpacked:

The sample opening a handle to itself to read 76567808 bytes:

We can see the binary decrypted in the memory allocation:

We can see the reference to RTLDecompressBuffer API, which is used to decompress the decrypted code 

Reference from https://blog.avast.com/andromeda-under-the-microscope

We can see that the malicious code in memory is searching for a binary pattern of 0x370xBD0x140xA1 in the decompressed binary created in memory:

It finds it in the following location:

 Also looking for binary pattern 0xB20x300xA30xD5:

 The malicious code then zero out the memory space where the original binary was loaded and then replace it with the decrypted an de-compressed code:

All sections are placed one by one:

The malicious code in memory is zeroed out and memory is freed:

Next we see that in the stack there is a pointer to API functions CreateThread and again RETN is used as an abnormal way to CALL this function and the parameters passed on to the API function can also be seen in the stack. The highlighted address 0x401467 will be the start address of the thread. I dump this location in the Dump area and place a breakpoint there so that when the thread is created the execution breaks at the entry point of the newly decrypted/decompressed malicious code:

We see below the jump to the highlighted location and the code breaks as expected but since Olly is looking at this as data and not code:

Let us right click on this entry point and ask Olly to re-analyze the code, which will result in the assembly code getting visible:

Next we see a call to NtSetInformationProcess. NtSetInformationProcess can change the privilege level of the program or it can be used to bypass Data Execution Protection (DEP). However in this case the processexecutionflag is 0x0c and not 0x22:

The execution crashes at a certain point due to an invalid memory location and required me to study the code and patch it manually so that the code can continue to run:

Once the code continues, it dumps many API names of ntdll, in the stack by going through the function export table and comparing the Crc32 hashes with hardcoded hashes. This is also mentioned in the avast blog, which are to be used by the final payload. again low level API calls used to bypass AV:

Next we can see that the Crc32 hash is being calculated using RtlComputeCrc32 of

Had to patch the Crc32 calculation and comparison. The JNE 00401786 kicks out of program so I started the code after that jumping to the equality branch so the code could continue:

Some more virtual memory allocated using the low-level NtAllocateVirtualMemory instead of VirtualAlloc:

Some more patching required:

We can see that memory is being copied from location 0x402028 to the newly allocated virtual space:

Some more memory allocations with RWE Access

We can see more copying of data from 0x7fea0000 memory location to 0x7fe90000

Some interesting strings:

We can see the strings used to create the JSON object which is supposedly communicated with C2 server. Also we can see the User Agent also:

More strings for JSON communication between bot and C2:

Persistence mechanism?

We can see reference to Zone.Identifier, which could indicate that this can be removed by the malware to bypass the "File downloaded from the internet" warning. We can also see reference to ms%s.exe the format of string used for dropped file in programdata. Also it sets the Hidden and ShowSuperHidden values in registry to prevent displaying hidden files.

We can see reference to cdosys.dll which could be a module of Gamarue to be downloaded from the C2 server.  We can also see another persistence mechanism whereby taskmgr.exe process execution option has the debugger set as the malicious program, so that whenever task manager runs, this program runs in the background as a debugger.

We can see a call to another low level API LdrProcessRelocationBlock to relocate the base to a new address:

 Again we see memcpy copying bytes from decrypted code to now another RWE location 0x7fe80000:

Then I see some strange code whereby the System32 directory is traversed for all dlls

I also see that strangely two bytes are copied from ntdll.RtlWalkHeap to 7FE80000. Maybe for runtime patching or self-modifying code:

I see a jump using CALL EDI to the 0x7fe90000 in-memory malicious code, using its entry point 0x7fe91493:

I observed a really unusual mechanism of code hiding and obfuscation, whereby the code in the 0x7fe90000 RWE memory section calls code in the 0x7fe80000 RWE section and this is remarkable evasion using code flow redirection techniques. The API calls of the final payload are all made from the 0x7fe80000 section, where 0x7fe90000 contains calls to 0x7fe90000. So as a result there are two layers of in-memory flow through code sections to perform action on objectives.

As you can see that the API call being made from the 0x7fe80000 for setting the error mode to suppress any display of errors:

We can see API call to get the %systemroot%:

Getting information about the volumes:

 Then there is a bunch of JMPs in 0x7fe90000, which again jumps to 0x7fe80000 for calling API functions. This is where most of the functionality/logic of the final code is centered:

We see API calls to enumerate running processes to compare against hard-coded hashes of black-listed processes to see if anyone of them is running. If yes then the program would exit. I had to patch the code flow once as one of the blacklisted process vmtoolssd.exe had a match against the processes running on my VM:

 API call to Process32First and Process32Next:

Now it calculates CRC32 for the process name. In the below case it is calculating it for “system” process:

The comparison of CRC32 against blacklisted process names is happening here:

Here the process will detect the blacklisted process of VM “vmtoolsd.exe” and terminate. So we need to patch the code here.

During the course of its execution if the malware detects analysis, it will go into an infinite loop of Sleep: We can see multiple Sleep calls:

Some more comparisons to Crc32 hashes. Below is the comparison with hash of process "sandboxierpcss.exe"

Next we see the CreateFileMapping and MapViewoffile API call, where it is mapping itself and can be used to load code in RAM or execute code without Windows loader:

Next we see 6000 bytes being copied from 0x400000 to 0x40000

We can see the copied binary:

Unmapviewoffile

Getting environment variable "4076290568" (UNICODE) and setting it if not found:

Getting the process filename:

Setting the process variable as the path to filename:

We can see using process hacker the environment value set:

 Next we see reference to msiexec.exe

Concatenation to create the full path to msiexec.exe:

Opening file msiexec.exe for reading:

Again the program crashes at this memset, where FFFFFF95 bytes are to be set?! Patching was of not much help at this stage. So I thought of looking ahead in the code and find as many other IOCs as possible and understand the working:

I can see a call to CreateProcess msiexec.exe in Suspend mode:

I could also see offsets to persistence keys

I can see where the malware forces the OS to not to display hidden files. This is again to hide its payload in programdata:

String format for the ms..exe file

This is where Zone information is removed by calling DeleteFile

I can also see the Image file execution persistence mechanism for taskmgr.exe and the name of the module cdosys.dll.
Reference: http://www.trendmicro.com/vinfo/us/threat-encyclopedia/malware/bkdr_androm.slw