Part I: MongoDB

Over the past few months, there has been a rise in ransomware-like attacks against many popular NoSQL databases, including MongoDB, Elasticsearch, and Redis. Many, if not all, of these attacks leverage insecure default configurations of the databases that allow for attackers to gain access to the systems and hold the data hostage while demanding a ransom to be paid. These insecure defaults often include no authentication and listening on a publicly addressable port, and the systems rely on the users to read the documentation to configure more appropriate security settings. Over the next few weeks, we will investigate just how rampant these types of attacks are, how we utilize the ThreatQ threat intelligence platform to house our research and utilize Operations for investigation and enrichment.

We will kick off this series by taking a look at MongoDB…

MongoDB

According to a Rapid7 study, it is estimated that roughly 50% of vulnerable MongoDB servers found in their scans were determined to be compromised. Earlier versions of MongoDB are configured in an insecure manner by default with no authentication and listening on all addresses. While this makes it easy to stand up instances for use, it makes it easy for attackers to scan for open MongoDB instances, gain access and hijack the data. Previous reports have stated that in a typical attack, the attacker will delete (or copy) the data and insert a new record that contains the ransom note with an email address and instructions on how to pay via Bitcoin.

Most recently, data from IoT toy-maker CloudPets had been leaked and ransomed exposing voice recordings of the kids owning the toys. Attackers had discovered the insecure MongoDB servers via Shodan.

To find out more about these attacks, we set up a vulnerable MongoDB instance in a popular cloud provider with default configuration: no authentication and publicly accessible. Within a few hours we were already receiving connections from a number of IP addresses scanning our database. The bulk of these hosts were just typical port scanners attempting to see what ports we had open on our system.

A week after setting up the MongoDB server we experienced our first compromise.

Figure 1: Screenshot of MongoDB Logs Showing First Compromise

We can see [Figure 1] that the attacker ran a script that listed the contents of our database (presumably to check if there was anything there), deleted all of the data and inserted a new record that contained a ransom note. It would appear that because the attacker deleted the data without copying it first that there is no actual way to restore the data by paying the ransom. We are able to correlate the source IP address of the attack based on the time and the connection number used in the MongoDB logs.

We determined this specific attack was a widespread, “spray and pray” style of attack because we saw the previous ransom notes were overwritten by new ransoms [Figure 2]; a behavior that was also seen in the wild.

Figure 2. Screenshot of MongoDB Showing Attackers Overwriting Ransoms

Enrichment via ThreatQ

To find out more about the sources of the scans and attacks, we ran a script leveraging the ThreatQ SDK that can parse the MongoDB logs and create all the indicators inside the ThreatQ threat intelligence platform.

Figure 3. Result of Parsing MongoDB Logs for Indicators

This script [Figure 3] parses out the IP addresses from the connection log events and associates the source port as an indicator attribute. We also parsed out the email addresses and FQDNs from the ransom notes inserted into the database by the attackers. As seen from the image above, we were able to parse out 26 unique IP Addresses, 2 email addresses, and 1 FQDN. The majority of the IP addresses were determined to be noise from hosts scanning our server. However, in Figure 4 we have a screenshot of the source IP address of the initial compromise.

Figure 4. Source IP Address of Initial Compromise

The next step in our investigation is to find out more about these indicators extracted from the logs. Do other intelligence sources have data on them? Have they been seen before in the wild? Are any of them related at all? To do this we leveraged ThreatQ Operations to pull in enrichment data and related indicators. First, using the Recorded Future Operation, we see that the source IP address of the first attack (51.15.51.27) was seen previously on 2/9/2017, is considered suspicious and is part of the “Recent Multicategory Blacklist.” We will pull these in and apply them as attributes to the indicator [Figure 5].

Figure 5. Enrichment of 51.15.51.27 via Recorded Future

Looking at the MongoDB logs, we discovered the subsequent attacks all originated from the source IP address of 95.183.53.190. Unfortunately, querying it via enrichment Operations resulted in very little information. This is quite common in scanner systems as they are created and destroyed frequently, making it difficult to find out more information. However, we still have two email addresses to research which happen to have the same domain name.

The FQDN, sigaint.org, was parsed from the email addresses found in the ransom notes inserted into the database. According to Wikipedia, “SIGAINT is a Tor hidden service offering secure email services.” We can run the same Recorded Future Operation against the FQDN to find more information. We are interested in determining if the domain is associated with any previous malicious behavior.

Figure 6. Recorded Future Results of sigaint.org

We see [Figure 6] that sigaint.org has been associated with previous ransomware attacks and has been tied to a few malware campaigns. Recorded Future also reports that the domain has been uniquely seen 195 times over the past 60 days.

The last pieces of data we investigate are the Bitcoin addresses. First, we created String indicators for each of the two Bitcoin addresses found in the ransom notes [Figure 7].

Figure 7. Example Bitcoin Address

Next, we created a custom Operation that queries Blockchain.info for transaction information. We are most interested in the number of transactions and total amount received as that can be an indication of how widespread this specific attack campaign is. When looking up the Bitcoin address associated with the first compromise, 16bm9fMWdmGCmhXDm3QqMgzwAFwPzLpGaR, we discovered that it has received a total of 0.4997062 BTC (~$640 USD) over 12 transactions [Figure 8].

Figure 8. Results of Blockchain.info Operation

However, the Bitcoin address associated in the subsequent compromises, 1B4kMRmY4yb4XW8hHnYRZT1WWNfnPfPbHR, did not return any data and had no transactions associated with it.

Conclusion

Ransomware attacks against MongoDB are rampant and there is little to no barrier of entry for attackers with automated code in the wild. In a matter of hours, our MongoDB server with default credentials was being scanned and within a week it was compromised multiple times. We leveraged the ThreatQ threat intelligence platform to ingest and parse MongoDB logs and utilized Operations for enrichment to find out more about the attackers. Utilizing Recorded Future data, we discovered that the sources of the attacks against our particular MongoDB server are part of an ongoing widespread campaign. With the 3.x release of MongoDB, the default configuration is set to only listen on 127.0.0.1 and not automatically open to the Internet. However, authentication is still disabled by default, so it is recommended to enable authentication with a strong password.