Thousands of unprotected Elasticsearch databases are being ransomed

The internet-facing instances are currently being accessed by attackers who remove the vulnerable databases and leave a ransom note instead.

Elasticsearch is a very powerful search engine for various databases, which is often used for manipulating internal data. While some Elasticsearch instances are only accessible from an internal network, a lot of others are actually internet-facing and can be accessed by anyone knowing the path, the URL leading to it.

The attack

Secureworks reports a new cybercrime campaign in which a lot of unsecured internet-facing Elasticsearch instances are used to steal databases and replaced with a ransom note. The note requests a ransom to be paid to get the database back (Figure A).

Figure A

The affected Elasticsearch that have been victimized were not secured in the sense that they were fully accessible without any authentication. The ransom note was stored in the “message” field of a unique index named “read_me_to_recover_database” by the threat actor. A unique contact email address was also left, in order for the victim to reach the attackers and negotiate the ransom.

Secureworks Counter Threat Unit (CTU) identified four different email addresses responsible for the compromise of over 1,200 different databases. Since the ransom note is always the same, it is probable that all of the 1,200 databases have been compromised by the same threat actor. It is yet not possible to determine the exact number of companies involved, since a vast majority of the databases were hosted on cloud providers networks and some databases probably belong to the same organization.

SEE: Mobile device security policy (TechRepublic Premium)

While the campaign is large, it does not really meet success for the threat actor. Secureworks reports two Bitcoin wallets being used by the attackers, but checking one of the two only shows two transactions, for a total amount of about $600 at the time of writing (Figure B).

Figure B

Secureworks CTU believes the attacker probably used an automated script to do all the work: Identify vulnerable systems, remove the database and drop the ransom note. It is likely that the data has never been backed up by the attackers, seeing the cost for storing data from 1,200 databases, according to the researchers.

The threat on unsecured databases

The same kind of attack has happened before, in 2017 for example, when 27,000 MongoDB servers were hit by a similar attack. In 2020, an attacker tried to ransom 22,900 MongoDB databases and threatened the victims to expose their data publicly and reach the General Data Protection Regulation (GDPR) enforcement authority to report the data leaks.

In 2018, an unsecured database belonging to an email marketing company led to the leak of 11 million records being exposed.

In addition to the ransom and data theft threat, it is also possible for threat actors to make copies of sensitive databases to help further compromises or to run cyberespionage operations.

SEE: Password breach: Why pop culture and passwords don’t mix (free PDF) (TechRepublic)

How to protect from this threat?

For starters, no database should be facing the internet if it is not strictly necessary. While it is mandatory for some businesses to have databases accessible online, a lot of the internet-facing databases are exposed just to make it easier for users.

Other common mistakes consist of misunderstanding database configuration tutorials, making honest mistakes when configuring those databases or even deploying misconfigured images of previous poorly configured databases.

In the case of Elasticsearch, guidance on securing it is provided on its website. Elastic asks users to never run it without security enabled, never as the “root” user and protect it from public internet, preferably behind a firewall or VPN. Role-based access controls should also be set, and appropriate privileges assigned to every user.

Should a database really need to be accessed from the internet, it should be protected additionally by strong authentication. Multi factor authentication (MFA) should be deployed, so that even if an attacker owns valid credentials to login, he/she would not possess the second channel of authentication. It is possible to configure Elasticsearch with MFA, be it a text message on a mobile device or a token on an authentication tool like Google Authenticator.

Disclosure: I work for Trend Micro, but the views expressed in this article are mine.