How to know if your Drupal site has been hacked by Drupalgeddon 2 (CVE-2018-7600)

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):

1. 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.
2. 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 following

     exec

   • As a last resort, make a visual inspection of the file names that look like the above.
3. 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.

4. 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
   

5. 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)
   

6. 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.

Contact Us