Analyze a cross-platform DDOS botnet

Some LINUX malware samples related to DNS amplification attacks have been learned from the recent post "malware must die. I am very interested in linux malware research, and this is very special, because he has a DDOS attack module, so I want to know more.
 
Run the obtained malware in the linux sandbox and connect it to C & C. Although I didn't see any DDOS attack activity, I analyzed it through PCAP (a tool for getting HTTP information), and the fluctuating image is visible at the bottom of the article.

The malware was downloaded from hxxp: // 198.2. [.] 192.204: 22/disknyp. The MD5 Hash Value of the sample is 260533ebdda-c3075c9dddf7784e86f9.
Location of C2: 190.115.20.27: 59870. According to the information provided by PCAP, the time for the compromised host to connect to C2. After the connection, the intruded host sends the current Linux kernel information-Linux 2.6.32-33-generic-pae.

Interestingly, C2 is a persistent connection that keeps the remote host connected on port 59870. At, C2 sends 75 bytes of hexadecimal information:

About every thirty seconds, C2 sends a new 75-byte sequence, for example:

01:00:00:00:43:00:00:00:00:fd:05:00:00:00:00:00:00:01:00:00:00:01:00:00:00:80:d4:07:c6:9c:50:00:01:00:00:00:00:00:00:00:1e:00:00:00:00:04:00:00:00:04:00:00:10:27:60:ea:ac:f5:a5:8f:ac:f5:a5:8f:00:00:00:00:00:d4:07:c6:9c:50:00

01:00:00:00:43:00:00:00:00:fe:05:00:00:00:00:00:00:01:00:00:00:01:00:00:00:80:d4:07:c7:d4:50:00:01:00:00:00:00:00:00:00:1e:00:00:00:00:04:00:00:00:04:00:00:10:27:60:ea:ac:f5:a5:8f:ac:f5:a5:8f:00:00:00:00:00:d4:07:c7:d4:50:00

01:00:00:00:43:00:00:00:00:ff:05:00:00:00:00:00:00:01:00:00:00:01:00:00:00:80:d4:07:c6:9b:50:00:01:00:00:00:00:00:00:00:1e:00:00:00:00:04:00:00:00:04:00:00:10:27:60:ea:ac:f5:a5:8f:ac:f5:a5:8f:00:00:00:00:00:d4:07:c6:9b:50:00

Like a counter, each time it increments from each sequence of C2 and changes between 0XC6 and 0XC7 until, the changed value is:

01:00:00:00:43:00:00:00:00:1d:06:00:00:00:00:00:00:01:00:00:00:01:00:00:00:80:73:ee:ed:f5:58:1b:01:00:00:00:00:00:00:00:0c:00:00:00:00:04:00:00:00:04:00:00:10:27:60:ea:ac:f5:a5:8f:ac:f5:a5:8f:00:00:00:00:00:73:ee:ed:f5:58:1b

01:00:00:00:43:00:00:00:00:1e:06:00:00:00:00:00:00:01:00:00:00:01:00:00:00:80:7a:e0:22:c7:58:1b:01:00:00:00:00:00:00:00:0c:00:00:00:00:04:00:00:00:04:00:00:10:27:60:ea:ac:f5:a5:8f:ac:f5:a5:8f:00:00:00:00:00:7a:e0:22:c7:58:1b

01:00:00:00:43:00:00:00:00:1f:06:00:00:00:00:00:00:01:00:00:00:01:00:00:00:80:0e:11:5f:4a:58:1b:01:00:00:00:00:00:00:00:0c:00:00:00:00:04:00:00:00:04:00:00:10:27:60:ea:ac:f5:a5:8f:ac:f5:a5:8f:00:00:00:00:00:0e:11:5f:4a:58:1b

01:00:00:00:43:00:00:00:00:20:06:00:00:00:00:00:00:01:00:00:00:01:00:00:00:80:3d:84:e6:15:5b:1b:01:00:00:00:00:00:00:00:0c:00:00:00:00:04:00:00:00:04:00:00:10:27:60:ea:ac:f5:a5:8f:ac:f5:a5:8f:00:00:00:00:00:3d:84:e6:15:5b:1b

The robot replies again in a 27-byte sequence, but the decimal offset 19 now has a value between 0 and 2:

00:00:00:00:00:00:00:00:00:00:00:00:00:00:00:00:00:00:00:00:00:00:00:00:00:00:00

00:00:00:00:00:00:00:00:00:00:00:00:00:00:00:00:00:00:00:01:00:00:00:00:00:00:00

00:00:00:00:00:00:00:00:00:00:00:00:00:00:00:00:00:00:00:02:00:00:00:00:00:00:00

00:00:00:00:00:00:00:00:00:00:00:00:00:00:00:00:00:00:00:00:00:00:00:00:00:00:00

00:00:00:00:00:00:00:00:00:00:00:00:00:00:00:00:00:00:00:00:00:00:00:00:00:00:00

Memory image fluctuation diagram:
Linux_pslist

The start time of the "disknyp" process is, the PID is 1241, and the sub-process is not recorded.
Linux_lsof-p1241

"Disknyp" process, PID 1241
Linux_proc_maps
The path of/tmp/disknyp is the original disknyp path. Two files are generated in/user/tmp/: "task.1241.0 × 8048000. vma" and "task.1241.0 × 8168000. vma ".
Task.1241.0 × 8048000. vma: 32-frequency audio file. Check the code in it:

Seeing the string "fake. cfg" officially related to the malware, I tried to find the original/tmp directory in the file:

Linux_yarascan
Let's use the "yarascan" plug-in to see if there is any reference elsewhere in this image.

We can see that the string "fake. cfg can only be found in the "disknyp" process whose PID is 1241. Use the "linux_find_file" plug-in again, and we can see "fake. cfg content at node 0xed9dc088:
 


[Original article link]