The indexes reside on various versions of Elasticsearch and require no authentication to read or write. In each case, data held in the databases was replaced with a ransom note stored in the 'message' field of an index called 'read me to recover database'. Inside the 'email' field is a contact email address. CTU researchers identified four distinct email addresses used in this campaign.
CTU researchers identified over 1,200 Elasticsearch databases that contained the ransom note. It is not possible to determine the actual number of victims because the vast majority of the databases were hosted on networks operated by cloud computing providers. It is likely that some databases belong to the same organisation, but identifying specific victims was not possible in most cases.
The campaign is broad, but the ransom payment is comparatively low. CTU researchers identified over 450 individual requests for ransom payments, totaling over US$280,000. The average ransom request was approximately US$620 payable to one of two Bitcoin wallets. As of this publication, both wallets are empty and do not appear to have been used to transact funds related to the ransoms.
While this campaign appears to be unsuccessful, it represents a risk to organisations hosting data on internet-facing databases. Unsecured Elasticsearch instances are trivially easy to identify using the Shodan search engine. Instructions on how to identify unsecured Elasticsearch databases are available.
This malicious activity is not unique to Elasticsearch. In 2020, third-party researchers discovered that approximately half of exposed MongoDB instances were wiped and replaced with a similar ransom note. Exploiting unsecured databases is not limited to data theft and extortion campaigns. Threat actors seeking sensitive information relating to specific organisations could easily build searches that identify relevant data in the indexes of internet-facing databases.
When a database requires remote access, organisations should implement multi-factor authentication (MFA) to protect internet-facing services. Organisations should also review cloud providers' security policies and not assume that data is secured by default.