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.


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


All samples share the same C2 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.



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


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.


download servers

vbot1 MD5


vbot1 C2 -port 2017

vbot2 MD5


vbot2 C2