In 2017 and 2020 we saw the oddest campaign – ‘Meow’ – targeting unsecured databases such as MongoDB, Elasticsearch, Cassandra, CouchDB, and other software such as Hadoop clusters, FTPs, Jenkins etc. The Modus Operandi was very simple finding an exposed instance, deleting everything, and destroying data without any explanation. Back in 2017 and 2020, it was quite a conundrum. There was little information about the attack and attackers. Now, the threat actor is back…
One of our honeypots, a Jupyter notebook instance, captured this week a renewed ‘Meow’ campaign. Most of the mystery is still there, but some of the scripts were captured, and the infrastructure of the attacker was further investigated.
In this attack, the threat actor initially accesses a misconfigured Jupyter Notebook instance, most likely found using a Shodan search. They then initiate a dash shell and start to gather information about the victim, including user id, processor type and architecture, and operating system name and release.
Subsequently, they downloaded the malicious script from the shared file server and ran it, after installing the relevant python packages, and running it on the notebook.
The script ‘foo’ contained 1,354 IP addresses, targeting Elasticsearch and MongoDB databases. Based on a comment in the script, this data was taken from Shodan.
Three days later another script – ‘bar’ – was used to attack via our honeypot. It is a more modest script with just 15 IP addresses. Seems like it is targeting Hadoop clusters, but the deletion function is using Pymongo library which is more suitable for MongoDB instances.
The Modus Operandi remains odd, as the attacker uses Python script to drop databases.
Three years later, the Meow campaign is using exposed Jupyter instances to run its code. Interestingly enough it is not deleting the Jupyter once it is done deleting the databases.
The scripts ‘foo’ and ‘bar’ were downloaded from the shared file server hosted on ‘bitcoinshell.mooo.com’. Anyone can open an account, and store files on this server. In 2017 (based on the earliest file), Cursor – interesting naming choice – created this account and uploaded some files.
In the file system there is another file eltest.py which is very similar to ‘foo’ and ‘bar’, containing IP addresses and erasing script.
In total we saw 1,283 distinct IP addresses targeted by this threat actor.
Further analysis of the file storage server shows that the earliest timestamp is on the test.html file, back from 2017, which is close to the first attack documentation (we found). The updated files ‘foo’ and ‘bar’ shows that they were modified recently (few days ago).
In 2020 bleeping computer published a blog about this campaign, one comment caught our eye, possibly posted by the threat actor, or at least someone who tries to justify such campaign, stating that if a company mistakenly exposes virtual assets, “it was the right thing to do!” to delete this asset.
