According to a blog post by Ofri Ziv, who leads the Detecion team at Guardicore, the attacks look like an evolution of the MongoDB ransomware attacks first reported earlier this year by Victor Gevers.
He said that hundreds of databases were affected by the attacks, which began on February 12 and lasted 30 hours, and which were all traced back to one IP address, 220.127.116.11, an IP address hosted by worldstream.nl, a Netherlands-based web hosting company.
The hosting company was notified and the attacks and Ziv said the suspected the attacker was “running from a compromised mail server which also serves as HTTP(s) and FTP server.”
He added that the attack starts with brute-forcing the root password for the MySQL database. Once logged in, the MySQL databases and tables are fetched. The attacker then creates a new table called ‘WARNING’ that includes a contact email address, a bitcoin address and a payment demand.
Ziv said that in one variant of the attack the table is added to an existing database; in other cases the table is added to a newly created database called ‘PLEASE_READ’.
“The attacker will then delete the databases stored on the server and disconnect, sometimes without even dumping them first,” he said.
The ransom note marked as “please_read” claims the database is backed up to the hacker’s servers. Victims then have to email the hacker detailing the victim’s IP address or database name.
The other “warning” demand asks victims to pay the ransom demand by visiting a site located in the dark web before the database is recovered.
The sites use two different Bitcoin wallets and Guardicore noted that based on Blockchain public information people have been paying up.
“Naturally, we cannot tell whether it was the attackers who made the transactions to make their victims feel more confident about paying,” said Ziv.
“Before paying the ransom we strongly encourage you to verify that the attacker actually holds your data and that it can be restored. In the attacks we monitored we couldn’t find evidence of any dump operation or data exfiltration.
The firm said that organisations should ensure servers running MySQL are hardened against possible attacks.
“Also, make sure your servers require authentication and that strong passwords are in use. Minimising internet facing services, particularly those containing sensitive information, is also a good practice. Monitoring your internet accessible machines/services is crucial to being able to rapidly respond to any breach,” added Ziv.
Kevin Eley, vice president of sales – EMEA at TrapX told SC Media UK that this is an internet-bound attack, so internet facing MySQL servers are vulnerable.
“Stringent password policies, effective backup and an honest appraisal as to whether the database actually NEEDS to be internet facing will all help. Deploying MySQL deception emulations in a DMZ will help detect this attack early, potentially giving valuable advance warning if any of the other MySQL properties are at risk,” he said.
“In the event of an attack, verification that the data CAN be recovered, coupled with a company position on whether paying an attacker is a desired practise. A clear evaluation of the costs and benefits of retrieving the data via a payment alongside a balanced view of the costs to recover from backup and any potential data losses associated with that needs to be carefully weighed. It’s not ideal for organisations to pay the criminals although clearly in certain cases, companies feel that is there only option.”
Gavin Millard, EMEA technical director of Tenable Network Security, told SC Media UK that with the recent spate of cyber-criminals targeting devices with poor cyber-hygiene that are available on the Internet, it’s unsurprising to see the focus shift from MongoDB to MySQL.
“It’s not hard to spin up a new LAMP instance (Linux, Apache, MySQL and PHP) on one of the many cloud providers that allow it, but to do so securely takes steps that many skip. Cyber-criminals are targeting these systems with ease, creating scripts that take hours to write but can net a hefty profit when let loose to encrypt the contents of publicly available and poorly configured devices,” he said.
David Kennerley, director of threat research at Webroot, told SC Media UK that to mitigate such risks, organisations need to perform regular risk assessments as standard.
“Firstly, they need to understand what does and does not need to be internet-facing within the organisation. The items that do need to be protected accordingly, starting with checking and improving on set-up defaults.”
“Authentication levels for each product needs to be investigated, default options aren’t always the best. Where possible restrict access based on policy, investigating whether VPN and tunneling protocols would work for a particular use case.”
This article originally appeared on SC Media UK