New Elknot/Billgates Variant with XOR like C2 Configuration Encryption Scheme

liuya@360.cn

Network Security Research Lab, Qihoo 360

Overview

Elknot is a notorious DDoS botnet family which runs on both Linux and Windows platforms. It has several variants, and has spread over Internet for years. Many analysis work about this malware has been done [1][2][3][4]. Currently the most popular elknot variant is also called BillGates by some researchers because it is highlighted in using Bill and Gates modules [5]. Except for that, this variant is also highlighted in using the textbook version RSA encryption to hide the C2 configurations including server, port, campaign name, etc. Once decrypted, one or more C2 lines would be got. Each line has the format of “<C2 ip or domain>:<C2 port>:<Is Listener ?>: <IsService ?>: <Campaign Name>:<Enable Backdoor ?> ”[6].

Last September, we discovered a new elknot/BillGates variant, which uses a different C2 encryption scheme but reserves the existing DDoS attack methods and C&C communications.

This article will discuss the new elknot/BillGates variant with a focus on the updates from the previous version. The analysis work is mainly based on the following 2 samples:

Ø md5: 2579aa65a28c32778790ec1c673abc49, type: ELF32:Intel80386:UNIX-SystemV.

Ø md5: 474429d9da170e733213940acc9a2b1c, type: ftype=ELF32:Intel80386:UNIX-SystemV.

New Encryption Scheme

In the last variant, the RSA cipher text and parameters are stored in showable hex format in samples. It’s easy to get all the cipher text and RSA parameters using Linux tool of strings then get the plain C2 information by self-written RSA decryption tool. We have developed such an automated solution that works for all found BillGates samples.

Figure 1, RSA cipher text and parameters in sample

Then in September 2015, we began to see elknot/BillGates samples from which valid C2 configurations could be extracted but the servers could never be successfully contacted. The failed C2 were either fk.appledoesnt.com or 115.231.218.64. The failed servers All extracted C2 servers was either fk.appledoesnt.com or 115.231.218.64. The C2 port for fk.appledoesnt.com was always 3000, while both 8226 and 13864 were seen for 115.231.218.64. As the uncommon cases began to accumulate, we felt obliged to investigate. The suspicious samples were run in our sandboxes. It supprised us that the samples contacted the C2 servers that were contacted were neither fk.appledoesnt.com nor 115.231.218.64. Some of them were successfully contacted. We had to re-check our C2 extraction solution but no bugs were found. Then we began to doubt maybe new variant had appeared.

After some Bindiff and dynamic tracing work, it was soon confirmed that new variants with different C2 encryption scheme did emerge. The real C2 information was hidden by the still existing RSA cipher text with fake C2 servers of fk.appledoesnt.com and 115.231.218.64.

The new encryption scheme is composed of 2 functions. They are renamed as DecryptionC2Entry and Decrypt. Then entry function (DecryptC2Cfg) is called by CSysTool::Ikdfu94, which is responsible for decrypting the C2 configuration. The following figure shows the slight difference between 2579aa65a28c32778790ec1c673abc49 and 8285f35183f0341b8dfe425b7348411d in CSysTool::Ikdfu94.

Figure 2, differences of CSysTool::Ikdfu94 functions

The entry function, as shown in Figure 3, is responsible for the following 3 things:

1, locating the cipher text.

2, calling the Decrypt function to get the plain C2 information.

3, jumping to CUtility::Split to split the plain C2 information by splitter of “:”.

It is interesting that DecryptC2Cfg will not directly return to the calling place when it finishes, but jump to CUtility::Split. We think this is due to the fact that the decryption functions were inserted by some builder program, not generated by compiler. The original function called at 0x8077AB4 was CUtility::Split, as shown in the right snippet of Figure 2. After decrypting the real C2 configuration and overwriting the fake RSA plain text, a jump to CUtility::Split exactly keeps the execution flow proceeding normally. Other evidences for the above speculation are as follows:

1, the common shellcode technique of “call $+5” is used in DecryptC2Cfg for address locating.

2, the 2 decryption functions were both stripped, while it’s not true for all the other functions.

Figure 3, new encryption scheme’s entry function

The following is the Decrypt functions. It cipher text has fixed size, 0x40 here. The core decryption operation is to get each plain byte by XORing current byte its exactly next neighboring byte.

Figure 4, CFG of Decrypt() function

There exists another version of DecryptC2Cfg, as found in the sample with md5 of 474429d9da170e733213940acc9a2b1c. The difference is that the addresses of cipher text and flag are hardcoded.

Figure 5, Another version of DecryptC2Cfg() function

As for the Decrypt function, the same control flow graph was seen shared among all found samples.

When studying the found samples, we found it common that the decryption functions, aka DecrytpC2Cfg and Decrypt, are not inside any valid sections. The following is the code snippet found in the sample with MD5 of 474429d9da170e733213940acc9a2b1c. The code is responsible for calling the called DecryptC2Cfg with address of 0x8130800.

Figure 6, The DecryptC2Cfg() function not inside valid sections

It’s easy to see the sample sections with Linux tool of readelf. The following is the output of “readelf –S” for sample md5=474429d9da170e733213940acc9a2b1c. It’s obvious that the address of 0x813080 is not inside any section, but located in the gap between section 12 and 13. This provides the third evidence that the decryption code is generated by some 3^rd builder, not compiler.

Figure 7, the address of DecryptC2Cfg outside of valid sections

YARA Rule

We have written a YARA rule according to the 2 cases of DecryptC2Cfg functions as follows.

rule elknot_xor {

meta:

author = "liuya@360.cn"

description = "elknot/Billgates variants with XOR like C2 encryption scheme"

date = "2015-09-12"

strings:

//md5=474429d9da170e733213940acc9a2b1c

seg000:08130801 68 00 09 13 08 push offset dword_8130900

seg000:08130806 83 3D 30 17 13 08 02 cmp ds:dword_8131730, 2

seg000:0813080D 75 07 jnz short loc_8130816

seg000:0813080F 81 04 24 00 01 00 00 add dword ptr [esp], 100h

seg000:08130816 loc_8130816:

seg000:08130816 50 push eax

seg000:08130817 E8 15 00 00 00 call sub_8130831

seg000:0813081C E9 C8 F6 F5 FF jmp near ptr 808FEE9h

$decrypt_c2_func_1 = {08 83 [5] 02 75 07 81 04 24 00 01 00 00 50 e8 [4] e9}

// md5=2579aa65a28c32778790ec1c673abc49

.rodata:08104D20 E8 00 00 00 00 call $+5

.rodata:08104D25 87 1C 24 xchg ebx, [esp+4+var_4] ;

.rodata:08104D28 83 EB 05 sub ebx, 5

.rodata:08104D2B 8D 83 00 FD FF FF lea eax, [ebx-300h]

.rodata:08104D31 83 BB 10 CA 02 00 02 cmp dword ptr [ebx+2CA10h], 2

.rodata:08104D38 75 05 jnz short loc_8104D3F

.rodata:08104D3A 05 00 01 00 00 add eax, 100h

.rodata:08104D3F loc_8104D3F:

.rodata:08104D3F 50 push eax

.rodata:08104D40 FF 74 24 10 push [esp+8+strsVector]

$decrypt_c2_func_2 = {e8 00 00 00 00 87 [2] 83 eb 05 8d 83 [4] 83 bb [4] 02 75 05}

condition:

1 of ($decrypt_c2_func_*)

}

Figure 8, YARA rule to detect the mentioned variant

Statistics

After mining the sample database, we found that the first sample of this variant had appeared as early as April 2015. Currently there are about 750 of such samples were collected, with nearly 700 unique C2 servers extracted. We will keep on watching the growth of this notorious DDoS family in the future.

[2] http://blog.malwaremustdie.org/2014/11/china-elf-botnet-malware-infection.html

[3] When ELF.BillGates met Windows, https://thisissecurity.net/2015/09/30/when-elf-BillGates-met-windows/

[4] http://www.novetta.com/wp-content/uploads/2015/06/NTRG_ElasticBotnetReport_06102015.pdf

[5] http://www.kernelmode.info/forum/viewtopic.php?f=16&t=3099

[6] https://www.akamai.com/us/en/multimedia/documents/state-of-the-internet/bill-gates-botnet-threat-advisory.pdf