Akamai Diversity

Akamai Security Intelligence
& Threat Research

DrupalGangster: An old threat actor trying to cash-in off the latest Drupal vulnerability

Written by the Akamai Threat Research Team

Akamai Threat Research has observed an increase in attacks attempting to exploit a recent Drupal vulnerability (CVE-2018-7600).

Much like recent vulnerabilities in Apache Struts, attackers have attempted to use this exploit for remote command injection attacks and to harness the power of the botnet to join a herd of coin-miners for profit.

While the attacker did not use a large  number of machines for this, he did make  a fair amount of money - almost $11,000 USD so far. It's not enough to quit his job and start a life full of luxury, but considering the time spent vs money received - the attacker will be encouraged to pursue his criminal activities in the future.


  • Activity started with low  volume of activity, with a small number of the IP's generating most of the activity.

  • Volume increased later, hinting at an epidemic behavior.

  • Out of the top 10 targeted hosts, 9 are built with Drupal. This indicates that the generated list of hosts that is received by the post-attack script (scrape2.py) is very accurate and does a good job finding Drupal vulnerable hosts.

  • The activity dropped off on May 22nd. We speculate that either the attacker lowered the attack intentionally or that he encountered improved security controls in the targets

  • The attacker attacked 3600 hosts of an Akamai customer, about 1400 of them were secured with Akamai's Web Application Firewall and 100% of attacks were mitigated before reaching the target.

  • We suspect that during the attack the C2 also probed multiple hosts to detect drupal usage (without attacking). The vulnerable hosts were presumably added to the hosts aggregator and distributed to all attacking bots.



The spike in  attack traffic began on May 20th, and went on for about 24 hours. After the initial 24 hours, the attack traffic decreased. At the time of writing this publication , we still see attack traffic, but in much lower volume.


So what exactly did we see?

When we noticed the spike in the attack numbers, we first went straight to the data. The initial intent was to simply understand what are we seeing - was a customer being attacked? Should we communicate it to them? We didn't yet know what we were dealing with, so we had to understand the situation.


When we examined the data, we immediately saw that the behavior of all IPs involved in this attack was exactly the same: they attempted Command Injection by sending a request that contains the following:

"wget -o /tmp/a.sh"


So, naturally, we had to investigate this "a.sh" script.


We fetched the content at the URL and started analyzing the script. We noticed that it calls another script - "scrape2.py", so we went and analyzed that one as well.


The behavior of the initial script can be explained by the following simple chart:



Once running, the XMR miners (either XMRig/2.6.0-beta2 or lukMiner v0.10.7) are connecting to a popular pool service named dwarfpool (a pool is defined as a collection of miners used to solve a block more quickly than a single solo miner), whose payout is rewarded via RBPPS (Round Based Pay Per Share minus pool and transaction fees):


We can see the connection to dwarfpool in the following output lines:

[10:37:45] connecting to pool xmr-usa.dwarfpool.com:8080

[10:37:45] connecting to pool


Inspecting the packets sent during connection to the dwarfpool server reveals the actual wallet identifier used in the service:


We realized that this allows us to gain visibility into the entire history of the mining operation, including earnings, payout history, current status, hourly charts, and the number of active workers.

C2 Investigation

We investigated all the activity coming from the Command and Control IP address: It seems that during the attack, this IP scanned thousands of hosts for Drupal without attacking them. Twenty percent of these hosts were also attacked during the campaign. We suspect that the intent of the scan was to detect hosts that are based on Drupal framework and vulnerable to Drupalgeddon v2. These hosts may have been added to the vulnerable-hosts data source (y.php file) that the C2 holds and distributed to all the attackers in order to perform the attack.  


The Goal

The attacker's goal seems to be  to mine crypto coins. In order to achieve this goal, the attackers exploited a recent known drupal vulnerability. The vulnerability is recent and the patch still hasn't rolled out to all drupal applications. This allowed the attacker to inject the scripts that would download the miner and keep distributing the script to other vulnerable services. The attacker "prepared" his attack for two weeks and then escalated it in a 24-48 hour timeframe.

Traffic Distribution & Statistics


The attack seemed to start at the end of April -  initially with a low volume of attacks and a small set of participating IP addresses. A significant increase in volume began on May 19th, and reached its peak on May 20th at 00:00 - this is the spike we saw and investigated.The attack traffic started dropping on May 21st at the end of day.


Given all the data available to us i, we can get some interesting statistics regarding the origin of the traffic even before the massive attack. We see that before and after the spike, 90% of the malicious activity was generated by only 3.5% of the total number of IPs we saw during this time period. These 3.5% belong to hosting providers. There was a 90% overlap with the attacked hosts before and during the spike.


Now that we know what happened, let's talk numbers


After we found exactly what happened, how, and why, we wanted to understand the magnitude of this attack.

Let's look at the numbers:

  • Number Of IP's Flagged By WAF - 1,390

  • Number Of Source Networks - 490

  • Number Of Source Countries - 76

  • Number Of Attack Requests - 547,970

  • Number Of Attacked Hosts protected By WAF - 1,413

  • Number Of Overall Attacked Hosts -  3,682


Overall, this is an attack from a few thousands of IP addresses, targeting approximately3,600 Akamai customer sites. Customers who are using Kona Site Defender - a Cloud-based WAF solution -  have been protected through the duration of the attack, since the attack never broke through this layer of protection.


We can see that the activity started with a relatively small number of IPs in low volume and increased dramatically. The number of targeted hosts didn't change. We can assume that the attacker had a pre-prepared data set of vulnerable hosts that he attacked. The hosts that were protected and patched were presumably not harmed. Others that were successfuly compromised fell under the attacker's control and began participating in the attack, that may explain the increasing number of IP's.  


Let's look at the distribution of the attacking IPs, and more specifically - where they came from:  

Origin of Attack - Top Countries



Attack Requests

































Based on the number of attacking IPs in each country, we see that virtually all attacks were generated from multiple hosting providers. This indicates that the attacker distributed the malware sporadically on different servers, probably infecting them by exploiting drupal vulnerability.

Out of these top 10 attacked hosts, we found that at least 9 of them are based on Drupal framework. We wanted to check this so we can understand how well this attack is planned - and we can see that the discovery phase of it works pretty well and is identifying Drupal applications.

In order to identify the hosts that are based on Drupal, we used a passive fingerprint which is also an easter egg put in by the original Drupal founder. If you look at the Expires response header from the server you'll spot a specific value - 'Sun, 19 Nov 1978 05:00:00:00 GMT' which, not by coincidence, is the birthday of its founder.

We also found that at least 90% of them had a running web server (ports 80 & 443).

We sampled those IP addresses, and confirmed that those have an active Drupal backend. This confirms the suspicion that those are indeed vulnerable sites and were vulnerable to Drupalgeddon v2.


We definitely see a short learning curve for attackers that would like to maximize the ROI of their botnet by adopting new exploitation methods.

But, this aggressive change causes attackers to make more mistakes, such as leaving debug and half-baked commands within script files and exposing their public XMR office.

Lastly, the worm-like behavior contributed a lot to the quick growth of the botnet.



IPs and Hosts:

List can be found her IP list.xlsx


Leave a comment