The Gafgyt variant vbot seen in its 31 campaigns

LIU Ya -

Overview

Gafgyt botnets have a long history of infecting Linux devices to launch DDoS attacks. While dozens of variants have been detected, new variants are constantly emerging with changes in terms of register message, exploits, and attacking methods. On the other hand, their new botnets are usually short lived, with most of the C2s watched keeping active for only a few days. In this blog, I will introduce such a sort of variant. The key findings are as follow:

  1. This variant was active from mid-April to mid-June. In total 31 campaigns for this variant were detected, from which 572 samples were captured. They were spread to build 19 botnets.
  2. This variant evolved through 2 versions. Both have a characteristic register message template “ver:%f:%s:%d” that includes a rarely seen format specifier “%f”.
  3. Mirai code was heavily used in both versions, which makes it possible analyze them with the extracted Mirai configurations.
  4. The same infrastructures, e.g., download servers, and filenames were observed being used in other families of botnet campaigns.
    This variant was named as vbot because vbot is found being used in an unstripped sample by the author. Accordingly the 2 versions are named as vbot1 and vbot2 in this blog.

vbot1

Only 1 vbot1 campaign was seen, with 26 samples captured, as shown by the following honeypot records.

All samples share the same C2 185.225.19.200:2017. Since in Gafgyt it’s common that the same source code will be compiled into binaries for different processor architectures, for simplicity, the following analysis is based on the unstripped ARM sample of f696375452d08eecbde14d64c74acdde. Compared with previous variants, vbot1 has a more concise main() function because most of its code was moved into 2 new functions named init_vbot() and main_c2_handler().

The function name init_vbot indicates that the author code named their botnet as vbot. It's responsible for initializing things including watchdog, configurations, and scanner. C2 communications are done in main_c2_handler(), where a loop of connection, registration and receiving command can be found, as shown below.

The characteristic register message template “ver:%f:%s:%d” is used in the registration block that tightly follows the connection block. From the unstripped symbols we can show that the 3 specifiers separately represent version, bot type and arch. The analyzed sample has version of 4.1.
Actually it’s just the rarely seen specifier “%f” that caused my attention to this variant because as far as I knew “%f” was not supported by Gafgyt. The original authors borrowed the design of C library functions printf and sprintf, and implemented a new function named sockprintf which can generate message according to the assigned string format and send it to the C2. A custom yet simple format controls is done inside sockprintf with “%f” not implemented. That function has been kept by most Gafgyt variants. When firstly encountering vbot’s register template, I imagined a new version of sockprintf. However, that’s obviously not true. To reuse sockprintf but avoid complex programming, vbot author turned to sprintf to generate the expected message then passed it to sockprintf with the supported specifier “%s”.
Similar to many Gafgyt variants, Mirai code can be found in vbot1. Due to its tight connection with the encrypted configurations, the borrowed code can be well analyzed with the extracted configurations. If you don’t know how to extract, please go to our VB2018 paper. The extracted configurations are shown below, with items annotated with its owner modules.

The commands are hidden in configurations. Except for attacking methods, vbot1 also supports remote update with the command UPDATE. Another worth mentioning feature is persistence mechanism, which is done by modifying crontab.

It’s strange that vbot1 was spread only once. After its campaign was firstly detected, 35 hours, or 1.5 days, later the first vbot2 campaign was seen from the same download server. Obviously the operators wanted to replace vbot1 with vbot2. The reason might be its buggy registration which always sends a 191-byte register message back to its C2 but only 18 bytes there are really useful, as shown by the following figure.

vbot2

In total 30 vbot2 campaigns were seen from April 16 to June 12, 2020, with 546 samples captured from 12 download servers. From those samples 13 C2 servers were checked. Detailed analysis shows except the registration code, vbot2 actually differs a lot from vbot1 in terms of code structure, attacking methods and Mirai configuration. The following analysis is based on the x86 sample f5b0ebebc924e69e34a4ddd145916594. It’s stripped but key function names have been manually restored.
Different from vbot1 but similar to many other variants, vbot2's C2 communications are done in main(), as shown below.

Nearly the same registration block as vbot1 can be found, with the 3 specifiers holding the same semantics. The analyzed sample has version of 1.5. The loop composed of “loc_804B80B -> REGISTRATION -> loc_804B863” is very similar to previous Gafgyt variants in terms of CFG node number and semantics. The blocks are separately responsible for establishing connection, registration, and receiving commands.
5 attacking methods were checked. All of them have been seen in other variants.

Some vbot2 samples, e.g., e36d96a74236038a348cfd667ca83528, have slightly different attacking method names, as shown below.

2 Mirai configurations were found. The only difference lies in the 0x28 item, as shown by the following 2 figures.


From the annotations we can see the Mirai code was mainly used in modules of watchdog, killer, scanner and rand alpha string generation. Since the 0x28 item corresponds to a message to be written to the STDOUT, and the second unprintable 0x28 item is probably caused by a typo from the author.
With the extracted configurations the differences from vbot1 are obvious. They are:

  1. vbot2 has different attacking methods from vbot1.
  2. While vbot1 hides commands in its configuration, vbot2 directly uses them.
  3. No remote update and persistence mechanism were found in vbot2.

Although those great differences suggest that vbot1 and vbot2 were actually derived from different code bases, I still think they were written by the same author(s) because:

  1. The shared register message template and registration implementation are unique enough.
  2. The first vbot2 campaign shared the same download and C2 server as vbot1 within a relatively short period of time (1.5 days).

vbot and the RHOMBUS malware

While the filename RHOMBUS was seen 4 times in vbot campaigns, its use in Gafgyt campaigns was much earlier[1], with the variant called RHOMBUS analysed in [2][3]. Here I make a simple comparison. In the blogged RHOMBUS malware dropper mechanism was found, with the dropper having the persistence ability across restart by modifying crontab. The dropped binaries, e.g., 269029c1554b13c3eccfaacf0196ff72 and ba42665872ea41e3d2edd8978bc38c24, actually belong to another Gafgyt variant that also heavily borrowed code from Mirai, as shown by the below figure.

From the above configuration we can see that obvious similarities exist between the RHOMBUS dropped binaries and vbot1. I think the most possibility is that vbot1 evolved from RHOMBUS malware with the following modifications:

  1. The dropper’s persistence mechanism was grafted to its payload. That’s why persistence items could be found in vbot1 configuration but not in the above figure.
  2. The register template was updated.
  3. c2 communications were moved to the so called main_c2_handler() function.

Other key points about RHOMBUS malware include:

  1. The register message template is "jm:_:%d" or jm:%s:%d.
  2. Similar to many Gafgyt variants, C2 communications were done in main().
  3. The Gafgyt characteristic function initConnection() was removed with its code broken down into snippets that can be found in main().

Conclusion

I have introduced a short lived Gafgyt variant vbot. During its 2 month life, 31 campaigns were seen to build 19 botnets. From vbot we can learn that it’s easy for Linux IoT botnet authors to quickly write new variants, which might be due to the fact that dozens of Gafgyt and Mirai source has been leaked online. Once a new variant is written, the behind operators usually will spread it over and over with different campaigns to build multiple botnets. Such patterns have also been observed in other variants and families, e.g., Mirai. To fight such sort of fast emerging while short living botnets, automatic IoC extraction would play an import role for quick blocking or tracking. In VB2020 conference to be held in October, I will give a talk on that topic. I hope it will help you fight against Gafgyt botnets better.

IoC

download servers

104.244.75.12
142.11.194.209
185.172.110.248
185.172.110.249
185.225.19.200
192.119.66.66
192.129.188.98
205.185.123.101
23.254.164.76
45.84.196.148
50.115.173.131
85.92.108.211

vbot1 MD5

2a141cd2930536f74f51fb57adbb0236
8717baf17660d8e96813ccd99f32c0be
cc559b487e1ec18727f37006bd3395e0
f666c3398601cd1b017f8d4556cabbbc
6fb6aaa253c165636ee63a4fdcdb1b9e
f422707ac869240bfeea648b6f9b90ad
36997fd129a5ff09311da94c3814379c
790ae71c097662bf6efba92d2d633076
e420df68941cc7ce2d8dd4ba92fd360e
3e36440871a6e39ee87e6d7d1a42155a
ae50829a02e5265c590f2fff35e64c52
09ab7435c76df627a813fb75db15ce5d
43ee98318945a475b555045aed4f0e01
e4db8addb5123021e358576157e5e1c0
4147fb0fe442173558f86fe37728ecae
846d6ad9ea86e331f2e071eac6a269de
40b1bf1e415ae508f8a5b831c2f4e994
f696375452d08eecbde14d64c74acdde
98b07b087b98b8d679c9938b16ae4df3
aea960687f0e43b465198be7ffafcf82
3d596d37fe6536a2c759923d920f3e08
52c462f3b22646774219f91bfb44ae66
d2c273e758fd4ac2759ca1d63aafcf6c
bbee73ed05730ad95df7a77241207ea5
0f492673eb249fa1209512575040f62d
0e59d4a40bba390314ffa0713b18441c

vbot1 C2

185.225.19.200 -port 2017

vbot2 MD5

efabd7e734490b9ad12812982347f237
614581bba324c3550a18268a8cb9c221
86310b514c55d31db288a2bb2c1e6114
76d9c69036f1eaac8f7a90eba3a36bfc
e36d96a74236038a348cfd667ca83528
d45da804fd35cf502bf942ebfeb64064
90a633f30bdbb2b80642bb229d1605d1
c4391301645cc9df4da3657f4c88f7dc
8bef47e420d0cdf8d0ee69a5d1f5b74c
4c8cdcbaf16f39a461b0bf7052fe1ec3
d936a9226fbbe97993bbe604c8cd5458
125b99cc79808679a7461f1841fd80a5
3b7da3d39db6ec08373c1e4af79aff85
23f764f5f918746b9ffff952dd25cc21
6f24268273573fd5f07cacb00031f1a0
ecae928b4e4093489bd221986da39aba
d883d5a2bedf0c3a3da79358c06fa429
3e26626d4563f3199fde498d0ff9fe32
11c1d777b18ffc0f23d2435fdb4645dc
...

vbot2 C2

104.244.75.12_666
142.11.194.209_1337
142.11.194.209_17911
142.11.194.209_34
142.11.194.209_44
184.172.110.248_666
184.172.110.249_666
185.172.110.248_323
185.172.110.248_666
185.225.19.200_666
192.119.66.66_7331
192.129.188.98_323
205.185.123.101_666
23.254.164.76_107
23.254.164.76_33
23.254.164.76_89
45.84.196.148_1227
50.115.173.131_111
85.92.108.211_1447