Another look at a cross-platform DDoS botnet

[Nytro]

Another look at a cross-platform DDoS botnet

I learned from a recent "

Malware Must Die" post about a Linux malware sample that is associated with DNS amplification attacks. As mentioned in the MMD post, several researchers have posted on this, or similar malware. Since I'm particularly interested in Linux malware, especially if it has a DDoS component, I thought I'd also take a look.

I was able to get the malware to execute on my Linux sandbox and connect to the C&C. While I've yet to see any DDoS related activity, I did pcap the C2 comms and snap an image for Volatility analysis. Links to the pcap and memory image can be found at the bottom of this post.

The malware was downloaded from hxxp://198.2. [.] 192.204:22/disknyp

The MD5 hash value of the sample I obtained is 260533ebd353c3075c9dddf7784e86f9

The C2 is located at 190.115.20.27:59870

Referencing the supplied pcap, the compromised host connected to the C2 at 18:46 EST. Upon connection to the C2, the compromised host sends information about the current Linux kernel, in this case, "Linux 2.6.32-33-generic-pae"

[TABLE=class: tr-caption-container, align: center]

[TR]

[TD=align: center][/TD]

[/TR]

[TR]

[TD=class: tr-caption, align: center]bot sending kernel info to C2[/TD]

[/TR]

[/TABLE]

It's interesting to note that the bot's C2 communications is via a persistent connection. Unlike typical HTTP bot check-in traffic, this bot maintains a connection to the remote host on port 59870. Since this is all one huge session, if you attempt "Follow TCP stream" in Wireshark, it will take a bit of time to present the output.

The C2 then sends 4 bytes, "0x04 0x00 0x00 0x00" upon which the bot sends back 27 bytes of all 0x00.

At 21:13, the C2 sends 75 bytes of hex:

[TABLE=class: tr-caption-container, align: center]

[TR]

[TD=align: center][/TD]

[/TR]

[TR]

[TD=class: tr-caption, align: center]Initial 75 byte sequence from C2 to bot[/TD]

[/TR]

[/TABLE]

Approx. every thirty seconds, the C2 sends a new 75 byte sequence to the bot, 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

Byte offset decimal 09 appears to be a counter, incrementing by one each time on each sequence from the C2. The contents at decimal offset 28 and and 71 initially vary between 0xC6 and 0xC7. This continues until 22:06 EST when the pattern changes and varied values are seen:

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 bot's replies again replies with a 27 byte sequence, however decimal offset 19 now has a value that will vary 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

Volatility

Some basic Volatility analysis of the memory image yields the following:

linux_pslist

[TABLE=class: tr-caption-container, align: center]

[TR]

[TD=align: center][/TD]

[/TR]

[TR]

[TD=class: tr-caption, align: center]linux_pslist[/TD]

[/TR]

[/TABLE]

The 'disknyp' process started at 23:45 UTC with PID 1241. Ran with user privs and no child processes were noted.

linux_lsof -p1241

[TABLE=class: tr-caption-container, align: center]

[TR]

[TD=align: center][/TD]

[/TR]

[TR]

[TD=class: tr-caption, align: center]linux_lsof for PID 1241[/TD]

[/TR]

[/TABLE]

Process 'disknyp', PID 1241 has /dev/null open as well as socket:[6931]

linux_proc_maps

[TABLE=class: tr-caption-container, align: center]

[TR]

[TD=align: center][/TD]

[/TR]

[TR]

[TD=class: tr-caption, align: center]linux_proc_maps for PID 1241[/TD]

[/TR]

[/TABLE]

Note that /tmp/disknyp is the path where 'disknyp' was originally executed. Dumping the two segments at '/usr/tmp' produces two files, 'task.1241.0x8048000.vma' and 'task.1241.0x8168000.vma'.

Running 'file' on the segments shows:

task.1241.0x8048000.vma: ELF 32-bit LSB executable, Intel 80386, version 1 (SYSV), statically linked, stripped

Dumping strings for that segment shows:

[TABLE=class: tr-caption-container, align: center]

[TR]

[TD=align: center][/TD]

[/TR]

[TR]

[TD=class: tr-caption, align: center]section of 'strings' output for PID 1241 segment 0x8048000[/TD]

[/TR]

[/TABLE]

We note the string "fake.cfg" that was mentioned in other posts related to this malware. Attempting to find the file in the original /tmp directory:

[TABLE=class: tr-caption-container, align: center]

[TR]

[TD=align: center][/TD]

[/TR]

[TR]

[TD=class: tr-caption, align: center]linux_find_file for 'fake.cfg'[/TD]

[/TR]

[/TABLE]

linux_yarascan

Let's use the 'yarascan' plugin to see if there are any other references to 'fake.cfg' in this image.

[TABLE=class: tr-caption-container, align: center]

[TR]

[TD=align: center][/TD]

[/TR]

[TR]

[TD=class: tr-caption, align: center]searching for other references to 'fake.cfg' using the linux_yarascan plugin[/TD]

[/TR]

[/TABLE]

We see that the string 'fake.cfg' is only found in PID 1241, 'disknyp'. Again using the 'linux_find_file' plugin, we can dump the contents of 'fake.cfg' located at inode 0xed9dc088.

[TABLE=class: tr-caption-container, align: center]

[TR]

[TD=align: center][/TD]

[/TR]

[TR]

[TD=class: tr-caption, align: center]Contents of 'fake.cfg'[/TD]

[/TR]

[/TABLE]

Final Thoughts

This appears to be some Proof of Concept or "testing" malware. There are several aspects to this sample that make me wonder if it was just put out there to see how quickly it would be detected and analyzed.

• Analysis of the original file as downloaded from hxxp://198.2. [.] 192.204:22/disknyp that it is statically linked, not stripped.
  

• The C2 communications is somewhat noisy. Maintaining a persistent connection with checkins every few seconds is not very stealthy.
  

• No attempt to hide the process. In hours of running this, I didn't see any child processes or variance in the process on the local host.
  

• 'fake.cfg' is created in the malware's working directory. 'fake.cfg' really?
  

• As I mentioned earlier in the post, I have yet to see any DoS related traffic from this sample. I'm also not aware of DoS activity being seen by other researchers. If anyone has learned otherwise, I'd love to hear from you!
  

Reference:

Packet capture of initial malware download and execution - disknyp.pcap

4.1 MB - MD5 hash - 4fb44dfa3d98e17f13c6befd55787582

Memory image of Ubuntu Server infected with 'disknyp' - linux_disknyp.zip

167 MB - MD5 hash of unzipped .vmem - 04831ad2fbd089c2c5b7b8dc657d0e7a

(Linux Volatility profile: LinuxUbuntu1004_pae32-33x86)

Posted by Andre M. DiMino at 4:36 PM

Sursa: Andre' M. DiMino -SemperSecurus: Another look at a cross-platform DDoS botnet

[Lordrayon]

NIce

[Gonzalez]

Danke!

-Gonzalez