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
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.
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.
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.
MD5:ae8f8cf967ca15a7689f2d1f79fbc5dc ELF 64-bit LSB executable, x86-64, version 1 (SYSV), statically linked, stripped Packer:upx Date:2021-10-30
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.
/bin/dockerlogger /usr/bin/dockerlogger /etc/iptablesupdate
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.
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
By dissociating the Base64 decoded result with
0x31 0x32 0x33, the following final result can be obtained
After decrypting C2, both
dockerlogger processes report device information to C2 via the path "/api/postip", and the format of the device information is
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)
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.
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.
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
-----BEGIN RSA PUBLIC KEY----- MFwwDQYJKoZIhvcNAQEBBQADSwAwSAJBAL3zj6XQt7gYe+L6oI/IUvlJNZVsg/JX\x0AC7TCnl9p1JfBJFdx+W9FTFnO2Fr8/hAUtf1NpP/WG2fgeG4Nvdcuyq0CAwEAAQ== -----END RSA PUBLIC KEY-----
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.
Hard-coded TOR domain name (decryption method is the same as C2)
DGA algorithm generates prefix strings, which are spliced with 3 suffixes (.com, .tk, .pages.dev) to form the domain name
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|
Part of DGA-generated domain names for Abcbot in October are shown below.
dgixyyfug.tk dgixyyfug.com dgixyyfug.pages.dev guyfixdyg.tk guyfixdyg.com guyfixdyg.pages.dev
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.
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 127.0.0.1 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); // 0.0.0.0 servaddr.sin_addr.s_addr = inet_addr("127.0.0.1"); 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.
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.
Readers are always welcomed to reach us on Twitter or email us to netlab at 360 dot cn.
C2 & Resource Server
dgixyyfug.tk dgixyyfug.com dgixyyfug.pages.dev guyfixdyg.tk guyfixdyg.com guyfixdyg.pages.dev gfgiudyyx.tk gfgiudyyx.com gfgiudyyx.pages.dev xgudyfyig.tk xgudyfyig.com xgudyfyig.pages.dev yugxdigfy.tk yugxdigfy.com yugxdigfy.pages.dev gdgiyyfxu.tk gdgiyyfxu.com gdgiyyfxu.pages.dev gdiuyyfgx.tk gdiuyyfgx.com gdiuyyfgx.pages.dev fgiudxyyg.tk fgiudxyyg.com fgiudxyyg.pages.dev ygfydgxui.tk ygfydgxui.com ygfydgxui.pages.dev
enjuyzkpr.tk enjuyzkpr.com enjuyzkpr.pages.dev rpzkjueyn.tk rpzkjueyn.com rpzkjueyn.pages.dev nkrjpezyu.tk nkrjpezyu.com nkrjpezyu.pages.dev unpeykzjr.tk unpeykzjr.com unpeykzjr.pages.dev ypnuejrkz.tk ypnuejrkz.com ypnuejrkz.pages.dev nerjyzkup.tk nerjyzkup.com nerjyzkup.pages.dev nejpzykru.tk nejpzykru.com nejpzykru.pages.dev knjpeuzyr.tk knjpeuzyr.com knjpeuzyr.pages.dev zrkyenupj.tk zrkyenupj.com zrkyenupj.pages.dev
188.8.131.52 China|Hong_Kong|Unknown AS63916|IPTELECOM_Global
0786c80bfcedb7da9c2d5edbe9ff662f 0f2619811ceaf85baa72f9c8f876a59a 1177c135f15951418219a97b3caad4e1 1a720cc74ecf330b8f13412de4d5646b 39d373434c947742168e07cc9010c992 3f277c7b4c427f9ef02cf8df4dd7be44 5d37a61451e5cfdeca272369ac032076 6e66456ffb457c52950cf05a6aaabe4a 6e66456ffb457c52950cf05a6aaabe4a 89ffd4f612ce604457446ee2a218de67 8f3558b29d594d33e69cea130f054717 a14d0188e2646d236173b230c59037c7 a17ea52318baa4e50e4b6d3a79fbd935 a4c7917787dc28429839c7d588956202 ae8f8cf967ca15a7689f2d1f79fbc5dc baeb11c659b8e38ea3f01ad075e9df9a c27d1c81a3c45776e31cfb384787c674 c64fbc7d3586d42583aa3a0dc3ea529f e535215fad2ef0885e03ba111bd36e24 e95c9bae6e2b44c6f9b98e2dfd769675
http://103[.209.103.16:26800/atk.tar.gz http://103[.209.103.16:26800/dd.sh http://103[.209.103.16:26800/ff.sh http://103[.209.103.16:26800/linux64-shell http://103[.209.103.16:26800/xlinux