Abcbot, an evolving botnet
Share this

Abcbot, an evolving botnet


Business on the cloud and security on the cloud is one of the industry trends in recent years. 360Netlab is also continuing to focus on security incidents and trends on the cloud from its own expertise in the technology field. The following is a recent security incident we observed, where the infected device IP came from multiple cloud provider platforms.

On July 14, 2021, our BotMon system identified an unknown ELF file (a14d0188e2646d236173b230c59037c7) generating a lot of scanning traffic, after analysis, we determined that this is a Go language implementation of Scanner, based on its source path "abc-hello" string, we named it Abcbot internally.

At the beginning, Abcbot was relatively simple, and could be seen as a scanner for attacking Linux systems, with a weak password & Nday vulnerability for worm-like propagation. One interesting thing is that Abcbot's source path has the "dga.go" string, but no related DGA implementation was found. We assumed that its authors would add this feature in subsequent versions, other than that, we did not paid too much attention to it.

As time passed, Abcbot has continued to evolve, and as we expected, it added the DGA feature in subsequent samples. Today Abcbot has the ability to self-updating, setting up Webserver, laughing DDoS, as well as worm like propagation.

On October 8, 2021, Trend Micro released an analysis of this family, which focused on the pre-SHELL scripts that spread Abcbot, but skimmed over the features of Abcbot itself.

Given that Abcbot is under continuous development, its features are constantly being updated, we decided to write this article to share our findings with the community.


  • On July 14, 2021, abcbot was first captured with the main functionality of Scanner,WebServer.

  • July 22, 2021, abcbot updated to include dga-related code in the self-updating function.

  • October 10, 2021, abcbot performed minor update.

  • October 12, 2021, another update, with some major code structure changes.

  • October 21, 2021, another update, adding the open source ATK rootkit to support DDoS functionality.

  • October 30, 2021, another update, abandoned ATK rootkit, to their own implementation of DDoS functionality.

Abcbot Overview

We use the latest October 30, 2021 sample as a blueprint, this version targets mainly on common databases and WEB servers, it uses weak password & Nday vulnerability to achieve worm-like propagation, the main focus is for DDoS.

It currently supports the following nine attack methods.

  • tls Attack
  • tcp Attack
  • udp Attack
  • ace Attack
  • hulk Attack
  • httpGet Attack
  • goldenEye Attack
  • slowloris Attack
  • bandwidthDrain Attack

Its basic flow chart is shown below.

Sample Analysis

We captured a total of 6 different versions of abcbot samples, and the sample of October 30 was selected as the main object of analysis in this paper, and its basic information is shown as follows.

ELF 64-bit LSB executable, x86-64, version 1 (SYSV), statically linked, stripped

Abcbot uses a standard UPX shell. When it runs in the compromised device, Abcbot confuses the user by copying itself into the following files, then starting the dockerlogger, iptablesupdate processes.


The iptablesupdate process is responsible for scanning for new infected devices, reporting the device information to C2, and waiting for the execution of DDoS commands issued by C2.

The dockerlogger process is responsible for turning the infected device into a webserver, reporting the device information to C2, and waiting for the execution of the Updata command issued by the update server, let’s take a closer look.

0x01: Uploading device information to C2

The current Abcbot samples are hard-coded with a encrypted C2 string ("GEVQYYdjQdquLemMLYlkLLXLQmq7NmL7NYXu"), which is encoded using Base64 & XOR encryption.

The Base64 decoding operation is shown below, and it can be seen that Abcbot changes the Alphabet value, which it uses as LMNu67PQX21pqrR3YZaDEFGbcVIJjkKWdefstghiBACHlSTUmO5noxyz04vw89+/

By dissociating the Base64 decoded result with 0x31 0x32 0x33, the following final result can be obtained

After decrypting C2, both iptablesupdate and dockerlogger processes report device information to C2 via the path "/api/postip", and the format of the device information is OS:%v\x09CPU:%v\x09HX:%vh\x09os-name:%v\x09lanip:%v.

Note both processes collect the same device information and call the abc_hello_util_Os_pz function. The only difference is shown in the figure below, which shows that the dockerlogger process appends "\td0.02" to the reported information, while iptablesupdate appends "\ ti0.02", where the "d" and "i" characters imply the process reporting the traffic, and "0.02" is similar to the version (in the October 21 sample, the version is "0.01").

The actual traffic generated is shown below.

0x02: Scan and propagation

The "abc_hello_plugin_StartScan" function is responsible for infecting new devices. Its logic is to generate random IPs, detect whether the ports on the IPs that can be attacked are open, and then attack the services by either going through the corresponding weak password list or using the Nday vulnerabilities.

The following code snippet shows that Abcbot tries to attack Weblogic.

In the Abcbot sample, you can clearly see the functions used in the attack on the relevant network services.

The weak passwords and vulnerabilities used by Abcbot are the following

  • SSH weak password
  • FTP weak password
  • PostgreSQL weak password
  • Redis weak password
  • Mssql weak password
  • Mongo weak password
  • WebLogic Vulnerability (CVE-2020-14882)

0x03: WebServer

Abcbot uses the "abc_hello_web_StartServer" function to start a WebServer on the infected device, listening on port 26800, and the supported methods and paths are shown in the following table.

Method Path
POST /api/postip
POST /api/configlist
POST /api/getlist
POST /api/check

The actual effect is shown in the following figure.

At present, the path that really being called is "/api/check", which is used to determine whether the device has already been infected by requesting the target ip:26800/api/check during the scanning and propagation process.

The other paths are only used to maintain connectivity and have no real use.When they are accessed, some logs files will be generated in the path "/tmp.abchello".

In fact, using "curl-X POST" cmd to test C2, you can find that the above 4 paths also exist on C2. The author of Abcbot seems to want to break the current C/S network model and bring the role of Bot in the network closer to Server. Therefore, we speculate that the network structure of Acbbot may shift to P2P.

0x04: Self-updating

On July 22, Abcbot introduced the "abc_hello_util_Updata" function to handle self-updates. Its logic is to request the "2.txt" resource from the remote server. The "2.txt" consists of two parts, which are in the format of "Resource(hex format)|digital signature(hex format)". When Bot successfully pulls the 2.txt, it will verify the digital signature by the following code snippet.

The hard-coded public key in the sample is




After the verification is successful, the Resource is further decomposed, and the format of the Resource is "cmd|downloader url| crc32|cmd2".

When the cmd is "alldown2", the downloader url is requested and the crc32 hash value of the file is verified. The downloaded file completes the process of self-updating.

The actual 2.txt obtained is shown below.

The Resource part is decoded in HEX format which represents update command.


There are 3 sources for the remote server domain name in this process as follows.

  1. Hard-coded TOR domain name (decryption method is the same as C2)

  2. DGA algorithm generates prefix strings, which are spliced with 3 suffixes (.com, .tk, to form the domain name

  3. DGA algorithm generates the string as a github account, and then gets the upgrade resources from this github account

The code snippet below is the process of Abcbot requesting 2.txt resources from DGA generated domain name and GITHUB repository.

The domain names used for the samples at each time point are shown below.

Date MD5 Res Tor Domain DGA Domain DGA Github
07-14 a14d0188e2646d236173b230c59037c7 0 0 0
07-22 e535215fad2ef0885e03ba111bd36e24 1 3/month 1/month
10-10 6e66456ffb457c52950cf05a6aaabe4a 1 3/month 0
10-12 39d373434c947742168e07cc9010c992 1 3/month 0
10-21 e95c9bae6e2b44c6f9b98e2dfd769675 0 27/month 0
10-30 ae8f8cf967ca15a7689f2d1f79fbc5dc 0 27/month 0

Part of DGA-generated domain names for Abcbot in October are shown below.

When Abcbot started to use DGA to generate domain names for updating servers, we grabbed some of them at the first opportunity, which allowed us to measure its size. From the current statistics Abcbot is not very large, with a total of 261 IPs.

The current distribution of infected hosts by service providers is shown below.

0x05: DDoS

On October 21, Abcbot introduced the "main_TimeDDos" function to support DDoS attacks, its logic is to request DDoS instructions from C2 via the path "/api/getlist", the instructions consist of 2 parts, "DDoS instruction (hex format) | instruction digital signature (hex format)". When Bot receives the instruction, it reuses the digital signature in the self-renewal subsection above for verification, and can only execute it after the verification is successful.

The actual traffic generated is shown below, the "73746f70" string before the "|" character is the "stop" instruction.

Interesting thing is that the sample on October 21 (md5:e95c9bae6e2b44c6f9b98e2dfd769675) uses the open source ATK Rootkit to implement the DDoS function.

Abcbot modified the main function in the ATK source code file share_atk_svr.c, and implemented a UDP server by monitoring SERV_PORT on through the following code. SERV_PORT has 4, respectively 88,89,90,91.

sockfd = socket(AF_INET, SOCK_DGRAM, 0);
bzero(&servaddr, sizeof(servaddr));
servaddr.sin_family = AF_INET;
// servaddr.sin_addr.s_addr = htonl(INADDR_ANY); // 
servaddr.sin_addr.s_addr = inet_addr("");
servaddr.sin_port = htons(SERV_PORT);

When Abcbot receives the command sent by C2, it forwards the command to the UDP server, and the ATK rootkit performs the DDoS attack. The code snippet shown below is exactly the DDoS command"BigUdp" forwarded to the rootkit.

The supported commands are shown below.

  • stop
  • syn
  • dns
  • bigudp

We do not consider this approach to DDoS attacks a good one, as ATK rootkit is stored in the form of source code on a remote server,


thus requires Abcbot to download the source code, compile, and load the rootkit module before performing DDoS attack, this process requires too many steps, and any step that is faulty will result in the failure of the DDoS function.

Apparently the author had same thoughts, and in the October 30 sample (md5:ae8f8cf967ca15a7689f2d1f79fbc5dc) an update abandoned the ATK rootkit and implemented its own attack module, with nine attack methods being supported.


In the process of reverse analysis, we found many oddities in Abcbot, such as "repeatedly reporting local device information, not registering DGA domain names, unreasonable exclusion of TOR & Github resource servers, and webserver functionality not really enabled", which gives us a feeling that Abcbot authors are testing various technologies. The update process in these six months is not so much a continuous upgrade of features as a trade-off between different technologies. Abcbot is slowly moving from infancy to maturity. We do not consider this stage to be the final form, there are obviously many areas of improvement or features to be developed at this stage. Let's wait and see what happens.

Contact us

Readers are always welcomed to reach us on Twitter or email us to netlab at 360 dot cn.


C2 & Resource Server

DGA Domain(October)

DGA Domain(November)

IP	China|Hong_Kong|Unknown	AS63916|IPTELECOM_Global



Sample MD5