Not only is crypto ransomware a threat to the integrity of data stored on end users’ hard drives and mapped network shares, but it has also been posing significant risks to web sites since late 2015.
The impact that web site administrators are facing is twofold. On the one hand, cyber criminals may stealthily embed rogue code into a web page so that every visitor falls victim to the ransom Trojan.
This methodology is inseparable from the activity of exploit kits that use software vulnerabilities on target computers to deposit malware.
The other side of the coin is that some ransomware strains can affect web sites themselves. To that end, the perpetrators leverage techniques like SQL injection to compromise a page, access its underlying database and encrypt all files in it.
Effectively, this routine denies the accessibility of the site contents. The infection will typically deface the website and replace its homepage with ransom demands. Although this might sound like a proof of concept, the above tactics have had quite a few real-world implementations.
Linux Web Servers Under Attack
A sophisticated ransomware sample dubbed Linux.Encoder.1 surfaced last November. The infection targeted web sites powered by Linux. When it emerged, the detection rate by popular antivirus suites was too poor to intercept the payload as it furtively infiltrated the server environment.
Linux.Encoder1 leverages known vulnerabilities in web site plugins and third-party applications, including shopping cart solutions. In particular, a likely entry point is a security loophole in Magento, a widespread open-source Content Management System (CMS).
The compromise results in the encryption of files located in the home and backup directories, as well as system paths storing the site’s code libraries, pages, images, and scripts. The ransomware creates a text file with recovery instructions in every folder containing the encrypted items.
The hackers’ demands are fairly high they ask for 1 Bitcoin, or about $550, to restore the web site data to its original state. The AES-128 encryption employed by this ransomware features too much entropy to brute-force, which has forced a lot of webmasters to pay up.
As opposed to the overwhelming majority of ransomware plagues, Linux.Encoder.1 does not set a deadline for completing the buyout and the ransom size does not double over time. That’s perhaps the only good news for the thousands of site admins who came across this strain.
WordPress CMS Exploited to Serve Ransomware
A number of major online resources, including The New York Times and The BBC, were hit in the course of this campaign. The offending code covertly redirected every person visiting the compromised sites to landing pages hosting the infamous exploit kit called Nuclear.
The exploit kit took advantage of outdated editions of Adobe Reader, Flash Player and Internet Explorer on visitors’ computers in order to execute TeslaCrypt. Although this particular ransomware strain is now defunct, it has been superseded by other threats such as CryptXXX. Therefore, the hoax is ongoing.
The Trojan doesn’t affect the content of hacked web sites proper, but it turns them into disseminators of cyber infection. The contaminated users run the risk of losing their valuable data, including Microsoft Office documents, media files, backups, and databases. Paying the ransom of $300 to $500 reportedly doesn’t always result in full recovery of the locked files.
Joomla CMS Isn’t Bulletproof Either
Threat actors in charge of the TeslaCrypt ransomware also compromise Joomla-hosted sites. The malware operators deploy the attacks via unpatched plugins. Obfuscated iframes generated in the course of this attack point to malicious URLs, most of which have “admedia” CMS component in them. Consequently, when a user visits the hacked page, the admedia gate triggers a redirect to the Nuclear or Angler exploit kits.
The rest of the attack is a mere technicality. The exploit kit spots software vulnerabilities on the user’s machine and injects the TeslaCrypt executable. This routine doesn’t involve a site defacement effect; moreover, the webmasters aren’t likely to detect the bad iframes easily. The outcome is obvious: visitors become infected, get their personal files scrambled, and face the “to pay or not to pay” dilemma.
CTB-Locker for Websites
The ransom Trojan called CTB-Locker operates in two realms at the same time: it targets end users and web sites alike. The web server edition was first spotted in the wild in late February 2016. It attacks WordPress sites via third-party plugins that have security flaws. Having compromised a web page, the ransomware substitutes the index.php or index.html file with a rogue one. The infection renames, encrypts and stores the original main web site file in the web root.
CTB-Locker uses AES-256 cipher to encrypt the content of the hacked web page. It also replaces the homepage with a screen explaining what happened and instructing the webmaster on how to send the ransom for recovery.
The malicious program generates two AES keys. One is used to encrypt and decrypt two files for free, which is an option “kindly” offered by the ransomware author. The other key is used to encode all the other files on the web site. The size of the ransom is 0.4 Bitcoin, or approximately $200.
Drupal Sites Defaced by Ransomware
Drupal is another popular Content Management System whose aficionados should take CMS updates more seriously. A series of attacks that broke out in March 2016 ended up locking about 400 Drupal web sites. The threat actors used an old vulnerability (CVE-2014-3704) to deploy an SQL injection attack without much effort. The scammers were able to delete the .htaccess file, change the administrative credentials and upload the ransomware.
The infection replaces the Drupal site’s homepage with a warning message that demands 1.4 Bitcoin to unlock the content. Effectively, this is a hijack rather than a crypto attack, because the pest does not actually encrypt any data. However, to regain full access to the site, the webmasters have to cough up some money.
How to Stay on the Safe Side
The Drupal incident is quite demonstrative as far as prevention goes. The vulnerability that the hackers exploited is two years old. This means that the webmasters didn’t update the CMS for an unthinkably long time. The same applies to the other cases as well.
The rule of thumb is to patch security holes in the Content Management System and third-party plugins as soon as these updates are available. Another important mitigation technique is to maintain secure backups of the site’s components.