As expected, since then we’ve been picking up various attack variants piggybacking on the Drupalgeddon 2.0 exploit, including remote scanners and backdoor attempts. In accordance with the latest dark web app hype, it wasn’t long until we started picking up cryptojacking exploit attempts directed at remote servers as well.
In our recent cryptojacking blog posts we covered a wide range of cryptojacking attack techniques, ranging from infecting a single target to a worm-like infection of the connected networks operating as miners farms. The above-mentioned attacks, part of the recent cryptojacking attack trend, are quickly becoming fashionable among web attackers – harnessing vulnerable machines as miners in their digital cave. In this post, we touch on yet another cryptojacking technique; distributing the mining effort beyond the targeted web application servers and internal network and reaching future visitors of the attacked web applications.
The latest critical RCE (remote code execution) vulnerability in Drupal — one of the most popular CMSs today — piqued the attackers’ interest who, in turn, harnessed recent exploits of this vulnerability to carry out various web application attacks. In a nutshell, the Drupalgeddon 2.0 vulnerability is caused by insufficient sanitation of arrays objects at Drupal’s core modules, which can be used as an entry point to remote execution of malicious code. During the inspection of the attacks blocked by our systems, we came across the “Kitty” malware, an advanced Monero cryptocurrency miner, utilizing a “webminerpool”, an open source mining software for browsers (see Figure 1).
Saving Some for Later
Once the Kitty bash script is executed, a PHP file named “kdrupal.php” (Figure 2) is written to the infected server disc. In doing so, the attacker reinforces their foothold in the infected server and guarantees dominance using a backdoor independent of the Drupal vulnerability.
Below is the Base64 decoded source code of the Kitty’s PHP backdoor which, although fairly light and simple, must be given some credit for using the sha512 hash function for protecting the attacker remote authentication.
Next, the script registers a time-based job scheduler (“cronjob”) which periodically re-downloads and executes a bash script from a remote host, every minute, giving the attacker the ability to re-infect the server or quickly change or push updates to the infected servers under their control.
Miner infections. The more the merrier.
Once the attacker gets a persistent hold of the server, a mining program “kkworker”, which is the well-known xmrig Monero miner, is installed and starts the mining process (Figure 5).
Gaining a single, strong mining server is great. The attacker, however, has much bigger plans – distributing the mining effort to the web app visitors. To do so, the attacker infects different web resources with a mining script – me0w.js (see details below).
In doing so, the attacker infects any future visitor on the infected web server sites to mine cryptocurrency for his disposal.
Lastly, to win over kitty lovers’ hearts, the attacker cheekily asks to leave his malware alone by printing ‘me0w, don’t delete pls i am a harmless cute little kitty, me0w’ (Figure 8).
… good thing we’re dog people. 😉
What we know about the author
The Monero address used in “Kitty” was also spotted at the start of April 2018, in attacks targeting web servers that run the vBulletin 4.2.X CMS. The attacker uploaded the malware to the infected vBulletin web servers, turning them into distribution centers and making it much harder to track the attacker. Additionally, the attacker was kind enough to update the malware version after every change in its code.
The first generation of the “Kitty malware” we discovered was version 1.5, and the latest version is 1.6. This type of behavior can be an indication of an organized attacker, developing their malware like a software product, fixing bugs and releasing new features in cycles.
Imperva customers protected
Imperva SecureSphere and Incapsula WAF customers are protected from this attack due to our zero-day and RCE detection rules. We also published a new dedicated security rule to provide maximum protection against possible mutations of this attack.