XOR DDoS botnet - 23rd February, 2017

Noticed it personally (on Ubuntu 16.10) helping another user in the last week or so.  Easy to fix but a PITA to deal with.  I was amazed deleting the created cron job watching it recreate itself within seconds.   Over the last week or so noticed one new application eating some 35% utilization and total upload (nic out) cumulation totals going to the Gb range bringing the new Intel iSeries (with 16Gb of RAM) down to a crawl not doing anything?
 
Following is a synopsis from Googling.
 
 
At the end of September 2014, a new threat for the Linux operating system dubbed XOR.DDoS forming a botnet for distributed denial-of-service attacks was reported by the MalwareMustDie! group. The post mentioned the initial intrusion of SSH connection, static properties of related Linux executable and encryption methods used. Later, we realized that the installation process is customized to a victim’s Linux environment for the sake of running an additional rootkit component. In this blog post, we will describe the installation steps, the rootkit itself, and the communication protocol for getting attack commands.

Installation Script & Infection Vector

The infection starts by an attempt to brute force SSH login credentials of the root user. If successful, attackers gain access to the compromised machine, then install the Trojan usually via a shell script. The script contains procedures like main, check, compiler, uncompress, setup, generate, upload, checkbuild, etc. and variables like __host_32__, __host_64__, __kernel__, __remote__, etc. The main procedure decrypts and selects the C&C server based on the architecture of the system.

In the requests below, iid parameter is the MD5 hash of the name of the kernel version. The script first lists all the modules running on the current system by the command lsmod. Then it takes the last one and extracts its name and the parameter vermagic. In one of our cases, the testing environment runs under “3.8.0-19-generic\ SMP\ mod_unload\ modversions\ 686\ “, which has the MD5 hash equal to CE74BF62ACFE944B2167248DD0674977.

The infection

During the rush of #shellshock we saw another new threat emerged. We saw an attack log of one-liner shell script being injected via ssh connection. By the attack source+CNC IP and the payload, this looks like a China crook's new hack scheme to spread new ELF DDoS'er threat. This is spotted silently spread during the ‪#‎shellshock waves, noted: it was NOT using #shellshock exploit itself.

pete_c said:

Read about this happening to a HS user a week or so ago (on Windows OS). Noticed it personally (on Ubuntu 16.10) helping another user in the last week or so.  Easy to fix but a PITA to deal with.  I was amazed deleting the created cron job watching it recreate itself within seconds.   Over the last week or so noticed one new application eating some 35% utilization and total upload (nic out) cumulation totals going to the Gb range bringing the new Intel iSeries (with 16Gb of RAM) down to a crawl not doing anything?

Click to expand...

 
Thanks for the heads up. I'm starting to poke around now to see how this thing works. I'd like to find out how the users are being infected since I'm a 99% Linux shop (hobby).

I did not pay much attention to this until I saw it happening while I was helping an Ubuntu 16.10 user.  What is a PITA is that it self replicates and it creates a unique application / profile per computer (AI like).
 
Here it was one day to the next where I saw a new box go to a crawl.  Using top saw weird named application running chomping at around 30% utilization.  It would not die when I tried to kill the process.  I then looked at a summary of network traffic and there was more going out then coming in.  (Gb's more).
 
The first time I tried in vivo the cron job self replicated went from once an hour to once every 3 minutes.
 
The fix is easy.  Just do that single user login to a console and delete the cron job and script and the files called by the cron job and the executable file that sits in your bin or sbin directories.
 
It seems to be a brute force entry and probably just scanning the Internet looking for open ports.
 
Here is a quick and dirty temporary fix.
 
Additional trick complementary to Serhii solution. Stopping all the processes can be difficult as this thing spams network and cpu. Therefore add this line to your /etc/crontab to automatically STOP all the nasty processes (stops all processes with 10 character in the name every three minutes):
 

Pete - this looks like a Linux only exploit.  Was that HS Windows system you were talking about running some type of SSH?   Seems this is only a brute force attack, so if your creds are complex, you should have no issues.

You are correct JonW.   I lumped the Wintel exploit with the above mentioned Linux exploit.  Apologies; updated OP.
 
That was on a Wintel Homeseer box and it was a service (malware) running.  Nothing to do with SSH.
 
ISP sent user a notice that he was exceeding his monthly allotment of data and his computer had slowed down.
 
It was a 'Character Generator' process / program running using up 80Gb of data per day.
 
The Character Generator Protocol (CHARGEN) is a service of the Internet Protocol Suite defined in RFC 864 in 1983 by Jon Postel. It is intended for testing, debugging, and measurement purposes. The protocol is rarely used, as its design flaws allow ready misuse.

A host may connect to a server that supports the Character Generator Protocol on either Transmission Control Protocol (TCP) or User Datagram Protocol (UDP) port number 19. Upon opening a TCP connection, the server starts sending arbitrary characters to the connecting host and continues until the host closes the connection. In the UDP implementation of the protocol, the server sends a UDP datagram containing a random number (between 0 and 512) of characters every time it receives a datagram from the connecting host. Any data received by the server is discarded.

Abuse

The service was used maliciously to crash MS DNS servers running Microsoft Windows NT 4.0 by piping the arbitrary characters straight into the DNS server listening port (telnet ntbox 19 | telnet ntbox 53).[1] However, the attack was presumably a symptom of improper buffer management on the part of Microsoft's DNS service and not directly related to the CHARGEN service.[citation needed]

UDP CHARGEN is commonly used in denial of service attacks. By using a fake source address the attacker can send bounce traffic off a UDP CHARGEN application to the victim. UDP CHARGEN sends 200 to 1,000 times more data than it receives, depending upon the implementation. This "traffic multiplication" is also attractive to an attacker because it obscures the attacker's IP address from the victim.

CHARGEN was widely implemented on network-connected printers. As printer firmware was rarely updated on older models before CHARGEN and other security concerns were known, there may still be many network-connected printers which implement the protocol. Where these are visible to the Internet, they are invariably misused as denial of service vectors. Potential attackers often scan networks looking for UDP port 19 CHARGEN sources.

So notorious is the availability of CHARGEN in printers that some distributed denial of service trojans now use UDP port 19 for their attack traffic. The supposed aim is to throw investigators off the track; to have them looking for old printers rather than subverted computers.