800+ IT
News
als RSS Feed abonnieren📚 MMD-0060-2016 - Linux/UDPfker and ChinaZ threat
💡 Newskategorie: Malware / Trojaner / Viren
🔗 Quelle: blog.malwaremustdie.org
Recent ChinaZ threat summary
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.
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 udner 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"
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
{
"ip": "172.87.28.220",
"city": "Cheyenne",
"region": "Wyoming",
"country": "US",
"org": "AS21859 Zenlayer Inc",
"postal": "82001"
}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: 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 in simple, so I am writing a walk through of its process in this reversing section to explain how this works.
When the malware runs, it will executed 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 check feasibility for cloning to a new process and fetching the online_config function. The process is as per coded below:
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_sleep, so then the data to be used for the further process in the main() function.
The attack's signal's 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:88 which is located in United States:
Up to this point we have 4(four) IP addresses in United States was abused by this actor. It seems the ChinaZ loves to abuse GoDaddy and 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 the web page which is serving it:
And yes, 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, while threading new process is good, and online_config is on looping and accessing the remote server for the attacking config with setting attack flag, the malware will printing message of "Waiting for command...".
If anything goes wrong in threading, it will sleep a second and restarting the whole process again, so, there is no exit in any kind of logic after this malware is run :). 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 and the bAttack (attacking flag) is marked, Linux/UDPfker will execute the below malicious activities:
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.
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
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 a form of simple flood of random strings to designated host:
Reversing PoC by behavior test
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: 
Samples. detection and epilogue
ChinaZ actor or group, is becoming known for long yet there is no stern reaction from authority in PRC in stopping this threat for good by direct action to the actor(s). Without cooperation from PRC government to stop this threat there is no way we can stop this for good.
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 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 radare reverse engineering of this threat, I suggest you to ping fellow expert reversers in radare.org community for more details om graphical forms, 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 recently.
Special thank you to our mate, Benkow for giving the hint of this new ELF.
Moral of the story for this analysis is; starting to investigate one single sample 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!! ...