How to know if your Drupal site has been hacked by Drupalgeddon 2 (CVE-2018-7600)
most site owners will never know
Here is the bad news: If you didn't update your site to the latest Drupal 7 or 8 releases before April 11, 2018, chances are your site and the server it sits on are now being compromised. And the longer your site goes without this updating, the higher the likelihood it's being used for cryptocurrency mining (or worse).
What makes this situation difficult for site owners is that you need to have some technical knowledge to determine whether your site and server have been hacked. In all the cases we've come across to-date, sites aren't being visibly damaged by this hack. Rather, the servers they sit on are being hacked to mine a cryptocurrency called Monero. In the process, hackers are creating a backdoor on these servers that allow them to come back at any time.
Following are 6 things you can do to determine whether your Drupal site has been compromised by Drupalgeddon 2 (CVE-2018-7600):
- Find out what version of Drupal your website is running.
As administrator, log into your website, visit the Reports page (usually at/admin/reports/status) and look for the Drupal version:- Running a version of Drupal 8.5 below 8.5.1 - assume you have been hacked.
- Running a version of Drupal 8.4 below 8.4.6 - assume you have been hacked.
- Running a version of Drupal 8.3 below 8.3.9 - assume that you have been hacked.
- Running a version of Drupal 7 below 7.58 - assume you have been hacked.
- Running a version of Drupal 6 - assume you have been hacked.
- Look for PHP files that don't belong to your website.
This attacks starts with a PHP file that is dropped usually at the root of your website (the same directory where index,php is located). If you find a PHP file with a name that looks like vtg14123.php or 8vs68geb.php or similar, then you've found the fingerprint of the attack.- If you use Git to control the versions of your code, you can run the following to see if a new file has been added (you will see files that have been modified or added):
$git status On branch master Your branch is up-to-date with 'origin/master'. Changes not staged for commit: (use "git add <file>..." to update what will be committed) (use "git checkout -- <file>..." to discard changes in working directory) modified: web/index.php Untracked files: (use "git add <file>..." to include in what will be committed) web/damage.php web/profiles/index.php web/sites/index.php web/themes/index.php web/world.php
- You can make a search for PHP files containing the following text:
($_COOKIE, $_POST)
...or the followingexec
- As a last resort, make a visual inspection of the file names that look like the above.
- If you use Git to control the versions of your code, you can run the following to see if a new file has been added (you will see files that have been modified or added):
- Look for a Trojan (or backdoor) that may have been added to your web server.
You can use ClamAV to look for Trojans. Here is an example from the real world using the Linux prompt:$ sudo clamscan --infected --recursive --remove --exclude-dir="^/sys" / /tmp/phpATZxhX_42l726l32t2us3lj: Win.Trojan.Agent-6442120-0 FOUND /tmp/phpATZxhX_42l726l32t2us3lj: Removed.
- Look for a cryptocurrency mining application running on your web server.
In Linux you can search for known scripts that are used to mine for cryptocurrencies. Here is an example that found a popular mining script:$ sudo grep -rnw '/' -e 'cryptonight' Binary file /run/log/journal/b22bf44f966e12ba962ba17f56d6dc85/system.journal matches Binary file /tmp/phpATZxhX_42l726ll4t2us3lj matches /tmp/phpATZvhX.c:2: "algo": "cryptonight",
Mining scripts often take lots of resources from your server and they can be spotted on Linux using a tool like called Top. Below you can see how the phpATZxhX_42l72 process is taking most of the resources:$ top PID USER PR NI VIRT RES SHR S %CPU %MEM TIME+ COMMAND 5221 www-data 20 0 617216 15124 1888 S 408.3 0.1 10025:27 phpATZxhX_42l72 8193 myuser 20 0 42460 3724 3080 R 4.2 0.0 0:00.76 top 1 root 20 0 37592 5068 3448 S 0.0 0.0 15:39.85 system
- Look for new open ports in your firewall.
We found a case where the port 2020 was opened to all traffic. A tight firewall should have only the minimum necessary ports open in order to conduct business, and it should have logs. E.g:$ sudo ufw status verbose Status: active Logging: on (low) Default: deny (incoming), allow (outgoing), disabled (routed) New profiles: skip To Action From -- ------ ---- 22/tcp (OpenSSH) ALLOW IN Anywhere 80/tcp (Nginx HTTP) ALLOW IN Anywhere 443/tcp (Nginx HTTPS) ALLOW IN Anywhere 22/tcp (OpenSSH (v6)) ALLOW IN Anywhere (v6) 80/tcp (Nginx HTTP (v6)) ALLOW IN Anywhere (v6) 443/tcp (Nginx HTTPS (v6)) ALLOW IN Anywhere (v6)
- Inspect your logs.
Nothing replaces a good old fashion log inspection. Look for things that look abnormal and indicate activity on some of the files above.
These are a few our learnings. We'll update this post as we learn more. In the meantime, don't hesitate to contact us if you need help.