Background
ChinaZ is the PRC (Public Rep of China) actor's made Linux ELF DDoS malware and its service. This threat has been covered several times in this blog post, several takedown efforts also had been taken, yet the threat is still lurking us, until now. Using specific indicators used during their infection effort, I can manage to trace the overall activity and their activity has been raising since early October 2016.
This post will include the recent indicators of ChinaZ threat, With aiming of the usage United States infrastructure that has always been aimed by this actor in their malicious action. Along with the C2 information that can be used as evidence collective purpose of the threat's activity.
ChinaZ is known for their aggressive effort in R & D by developing, testing and deploying a new coded malware in their operation, and in this post we will report the new payload used by the ChinaZ and they call it as "UDP F*ker". The variant looks new, from this point we will call it as Linux/UDPfker. Thank you to benkow for pointing us of this new payload.
ChinaZ recent threat summary
Since October the 6th, 2016, we detected infection efforts executed by this actors as per following timeline table, on several "victim boxes" by the threat:
By this data we can extract the infrastructure information that they are using as per follows:
The below infrastructure (in form of BGP feed) is under United States network, please see the timeline in JST on the picture above for matching the date of this service was rented.
---------------------------------
Attacker IP | Panel IP
----------------|---------------
139.205.96.130 | 121.10.172.185
222.186.56.176 | 220.169.242.158
14.157.74.180 | 222.187.221.224
139.205.124.174 | 222.186.21.202
61.180.70.49 | 112.74.28.133
14.157.74.81 | 192.169.136.53
139.204.25.47 | 222.187.239.242
123.191.11.197 | 43.248.8.171
123.191.66.176 | 116.31.123.159
119.86.39.175 | 61.160.215.153
121.18.231.85 | 61.147.110.13
172.87.28.220 | 171.92.208.129
14.157.74.173 | 192.169.180.138
61.147.110.23 | 180.97.220.28
222.187.224.159 |
121.10.172.185 |
112.74.28.133 |
222.187.239.242 |
---------------------------------
The last series of infection made was using Linux/Elknot and Linux/BillGates under CNC of:
172.87.28.220 | |21859 | 172.87.24.0/21 | ZNET | US | 222.cc | EightJoy Network LLC
192.169.136.53 | ip-192-169-136-53.ip.secureserver.net. |26496 | 192.169.136.0/21 | AS-26496-GO-DADDY-CO | US | godaddy.com | GoDaddy.com LLC
192.169.180.138 | ip-192-169-180-138.ip.secureserver.net. |26496 | 192.169.180.0/22 | AS-26496-GO-DADDY-CO | US | godaddy.com | GoDaddy.com LLC
With the hashes of:
(Linux/Elknot) 192.169.180.138:10991
(Linux/BillGates) 180.97.220.3:58595
(Linux/BillGates) hostname: "25000.valalala.com" IN A "180.97.220.3"
$ whois valalala.com | grep mail
Registrar Abuse Contact Email: abuse@godaddy.com
Registrant Email: "670128020@qq.com"
Admin Email: "670128020@qq.com"
Tech Email: "670128020@qq.com"
SHA1 (10991fuck) = f7c6333593993dcaeb66adec83f3c7b31d3080bd
SHA1 (10992fuck) = b4ca8bc6ba1520adb49b4f867c53409dbf405ab1
SHA1 (s58595) = 8fcfa3a683730c697bb4722f1b61c0ef56ea7b6a
SHA1 (u58595) = 23369f101a0f8210f4c2b87ede4821167f9893b4
The recent used web HFS panel is still up and alive by the time this analysis was written, as per shown in the below's picture:
123456.. the Linux/UDPfker
This a new malware used by ChinaZ actor that was served in the above mentioned HFS web server panel. The actor was distributing it via an infection efforts under filename of "123456" and I recorded an effort to infect this malware on October 26th 2016 as per shown in the log below:
The attacker IP 172.87.28.220 was listed as US infrastructure abused by this actor in the previous list. To be precise, is under the below GeoIP data:
2016-10-26|20:26:14| "172.87.28.220" | 192.169.180.138:55678/123456
And the actor was using this IP a lot of times to infect ChinaZ used payloads to all of us, as per below time table list:
{
"ip": "172.87.28.220",
"city": "Cheyenne",
"region": "Wyoming",
"country": "US",
"org": "AS21859 Zenlayer Inc",
"postal": "82001"
}
This is not good.
2016-10-16|23:52:43| 172.87.28.220 | 192.169.180.138:55678/10991fuck
2016-10-17|17:39:30| 172.87.28.220 | 192.169.136.53:55679/10992fuck
2016-10-24|22:28:28| 172.87.28.220 | 192.169.180.138:55678/u58595
2016-10-25|04:05:56| 172.87.28.220 | 192.169.180.138:55678/s58595
2016-10-25|04:07:32| 172.87.28.220 | 192.169.180.138:55678/10991fuck
2016-10-25|18:29:35| 172.87.28.220 | 192.169.180.138:55678/10992fuck
2016-10-25|18:30:19| 172.87.28.220 | 192.169.180.138:55678/10991fuck
2016-10-25|23:37:09| 172.87.28.220 | 192.169.180.138:55678/u58595
2016-10-25|23:44:18| 172.87.28.220 | 192.169.180.138:55678/s58595
2016-10-26|01:24:33| 172.87.28.220 | 192.169.180.138:55678/s58595
2016-10-26|02:28:58| 172.87.28.220 | 192.169.180.138:55678/monitorv
2016-10-26|20:26:14| 172.87.28.220 | 192.169.180.138:55678/123456
2016-10-28|16:46:38| 172.87.28.220 | 192.169.180.138:55678/10991fuck
2016-10-28|16:47:08| 172.87.28.220 | 192.169.180.138:55678/u58595
2016-10-28|16:47:13| 172.87.28.220 | 192.169.180.138:55678/10992fuck
2016-10-28|16:47:19| 172.87.28.220 | 192.169.180.138:55678/s58595
2016-10-28|21:52:59| 172.87.28.220 | 192.169.180.138:55678/10992fuck
2016-10-28|21:54:27| 172.87.28.220 | 192.169.180.138:55678/u58595
2016-10-28|21:54:27| 172.87.28.220 | 192.169.180.138:55678/10991fuck
2016-10-28|21:54:58| 172.87.28.220 | 192.169.180.138:55678/s58595
The usage of the United States network by ChinaZ is one of their typical modus operation, in order to spread their payload in wider ranged in this planet, to avoid blocking scheme from several networks that blocks China and Hongkong (which is very recommended blocking scheme for protocol like SSH, FTP, SFTPm etc, to prevent your network being visited by these threat)
No screenshot no love, so this is the proof of the same panel when "123456" payload was served:
Linux/UDPfker binary analysis
This is the binary:
..with the sections and program headers intact.
123456: ELF 32-bit LSB executable, Intel 80386, version 1 (GNU/Linux),
statically linked, for GNU/Linux 2.6.32,
BuildID[sha1]=413c18fca2c9f7cdb45a30aad9c6d660784e01c5, not stripped
SHA1 (123456) = "bafa9c87a03fda99bc62980a61c53666d758a613"
ELF Header:
Magic: 7f 45 4c 46 01 01 01 03 00 00 00 00 00 00 00 00
Class: ELF32
Data: 2's complement, little endian
Version: 1 (current)
OS/ABI: UNIX - Linux
ABI Version: 0
Type: EXEC (Executable file)
Machine: Intel 80386
Version: 0x1
Entry point address: 0x8049a1c
Start of program headers: 52 (bytes into file)
Start of section headers: 1149380 (bytes into file)
Flags: 0x0
Size of this header: 52 (bytes)
Size of program headers: 32 (bytes)
Number of program headers: 6
Size of section headers: 40 (bytes)
Number of section headers: 33
Section header string table index: 30
It seems the binary is in the testing stage by actor, since it is not prepared in the "well-done" state.
Reverse Engineering
The malware's work is simple, so I am writing a "walk-through" of its process in this reversing section to explain how this works. The source code for this malware is very few, and there are so many libcurl code and other libraries codes distorting the actual codes, please be careful in tracing them, always aim only process of the real malcodes one.
When the malware runs, it will first execute the below code:
Which is showing its original name and built date clearly:
As also per shown below when it runs..
At this point the malware checks the feasibility for cloning (by pthread) to a new process and fetching the online_config function. The process is as per coded below:
This malware will retry to make threat if the pthread creation fails, after a second of pause.
What resides in the online_config function is the data to be executed in coded instruction for the malware to attack, let's see the below cool r2 diagram to simplify the explanation on how it works:
Apparently Linux/UDPfker is checking for the online configuration data by launching a fork to keep checking a remote online web server's data by utilizing cURL library code. The data contents firstly checked by tools_analzy() which is firing strok() to check the format and then to examine its values, to then grab the token data to be saved in variables config_attack_ip, config_attack_port, config_attack_pack_length, config_attack_sleep (the meaning of each variable is self-explanatory). so then the data to be used for the further process in the main() function.
The attack's signal value was set as "0" or "1" in the online_config function, which the value of "1" means the config data is good, the target is lock and load in the memory, and the attack is ready to be performed.
By the time the analysis is written the URL that is being used by cURL to access the attack configuration data is located in the ip address of 166.62.125.38 which is also located in United States:
Up to this point we have collected 4(four) IP addresses in United States that were abused by this actor. It seems the ChinaZ lovesGoDaddy/SecureServer DC for his malicious purpose.
{
"ip": "166.62.125.38",
"hostname": "ip-166-62-125-38.ip.secureserver.net",
"city": "Scottsdale",
"region": "Arizona",
"country": "US",
"loc": "33.5092,-111.8990",
"org": "AS26496 GoDaddy.com, LLC",
"postal": "85267"
}
Yes, yes, no screenshot no love..so here we go, first the download URL in decoded C language:
And then this is web page which is serving the config:
And yes, also..no PCAP no love :
I think you can get all of the data, like time stamp, web server used, and etc detail for the incident response purpose.
Okay.. what happened next is, if threading for a new process is good, and online_config is on looping and accessing the remote server for the attacking config to set attack flags & attack variables, the malware will print message of "Waiting for command...".
If anything goes wrong in threading process, it will sleep a second and restart the whole process again, so, there is no exit 0 in any kind after this malware is running :).
The code for this part is shown in the radare graph as below:
..or see the red marked part in the reconstructed C code below:
In the end, after the online_config is checked, the attack target variables are filled and the bAttack (attacking flag) is marked, Linux/UDPfker will execute the below offensive DoS activities, under following steps:
The regenerated C code for the above steps is as per seen below:
1. Executing system command "shopt" with parameter to extend pattern matching features.
2. Utilizing "rm -rf", "egrep" and "ls" command to delete all saved ChinaZ files.
*) PS: above operations can lead to rm all files in workdir if shopt isn't installed.
3. Checking if the attack mode is set on ("1") at bAttack
4. Open socket connection to targeted service saved in config_attack_ip, config_attack_port
5. On attack flag is set, it forms strings to send by UDP connection to victim IP:PORT
(the length of the packet is defined in config_pack_length)
6. Checking if config_attack_sleep is exists and pause attacks upon instructed value.
7. Continue the process until bAttack flag is set to off (zero) & close connection.
8. Upon error in socket connection it will write message and retrying.
9. Loopback to the step 1.
The attack itself is a form of simple flood of random strings to designated host:
Reversing PoC by behavior test
Yes, no PoC, no love..so here we go!
Below is the screenshot of a session for this malware I executed by using the mentioned served CNC's web config data, as the proof of concept of the data reversed is correct:
It doesn't need a savvy memory debugging effort to PoC how it works, unless you want to be in very details, since the malware interface is rich with information needed with a plenty of printf or put messages on every conditions.
As you can see in the screenshot, the pthread was started.. all looks okay and entering the attack main loop (see the shopt error, I uninstalled this for the check purpose), ..and the malware config was downloaded, or else the "Config download successful" message won't appear:
...the data was checked without error then.. the bAttack flag is supposed to be set up then..but!! the target IP address' port 7777 was unresponsive, so there's no flood performed, and the value "60" was loaded by the malware as 60 seconds on config_attack_sleep causing a pause one minutes. After the pause it will restart the attacker's main loop again, and so on and on..
connect(3, {sa_family=AF_INET, sin_port=htons(88), sin_addr=inet_addr("166.62.125.38")}, 16 = 0
send(3, "GET /hconfig.php HTTP/1.1\r\nHost: 166.62.125.38:88\r\nAccept: */*\r\n\r\n", 66, ..
recv(3, "HTTP/1.1 200 OK\r\nServer: kangle/3.5.8\r\nDate: xxxxx Oct 2016 18:29:28 GMT\r\nX-Powered-By: PHP/5.3.29-upupw\r\nContent-type: text/html\r\nTransfer-Encoding: chunked\r\nConnection: close\r\n\r\n1f\r\n\r\n0,183.2.225.10,7777,0,1024,60\r\n0\r\n\r\n", 16384, 0) = 224
write(1, "\33[1;36m[Info]\33[1;33mConfig download successful!\n", 48) = 48
Friends, this is the Linux/UDPfker, that ChinaZ's new attacker toy.
Samples. detection and epilogue
ChinaZ actor or group, is known for long time, yet there is no stern result from authority in PRC in stopping this threat for good, by direct action to the actor(s). Without cooperation from PRC to stop this threat there is no way this threat can be stopped for good. Please help all of us to make internet to be a bit safer by stopping this badness.
In the Linux/UDPfker, The usage of libcurl for fetching the config is important to highlight here, since the libcurl is supporting to many protocol like HTTPS, FTP, IMAP etc.., with the usage of SOCKS proxy too. This can raise difficulty to dissect this threat.
The threat origin is ChinaZ, their signatures are all over the place, for instance, the usage of f-words or the specific mispell in variable names, it is their known trade mark.
The hash for samples are in this post, and ELF samples are all in the Virus Total.
The detection for the Linux/UDPfker is still obviously weak now (see below).
If you have any question about the radare2 graphical features for reverse engineering related to this threat, I suggest you to ping fellow expert reversers in radare.org community for more info, or leave a comment message in this post for me to try to assist. PS: We're not active in twitter anymore, DM messages maybe not being read.
Special thank you to our mate, Benkow for giving the hint of this new ELF.
The moral of the story for this analysis is: If you are starting to investigate one single sample, take it seriously in every aspects you can investigate, because that can lead you to the whole infrastructure of the badness behind it, so please be persistent and never giving up on analyzing new malware.
Stay save friends, and #MalwareMustDie!
Reversed, written and analyzed by @unixfreaxjp [link] on October 30th, 2016, Happy Halloween!!