Emory Healthcare patient data hijacked and held for ransom? (UPDATED)

Yesterday, I noted a somewhat alarming report that misconfigured MongoDB installations are being wiped by a hacker who steals the databases and then holds them for ransom of .2 BTC (approximately $200 at yesterday’s rate or $220 at today’s rate). This latest threat was reported yesterday by Catalin Cimpanu of Bleeping Computer after an ethical hacker, Victor Gevers, disclosed the discovery he had made as part of Project 366.

On December 27, Gevers had tweeted:

Gevers originally indicated that there were a few hundred affected databases, but by yesterday afternoon, John Matherly, the founder of Shodan.io, tweeted that there were now nearly 2,000 such instances of Harak1r1 hijacking databases for ransom.

By early this afternoon, that number had reportedly risen to 3,500, and there appeared to be 17  payment transactions to the specified Bitcoin wallet, suggesting that at least some of the victims are choosing to pay the ransom. The first payment to the BTC wallet was made on December 21.

Portal login for clinicworkflow.org

On December 30, MacKeeper Security Research Center discovered yet another misconfigured MongoDB installation that contained what appeared to be hundreds of thousands of patient records and other sensitive information of Emory Healthcare patients. The IP address of the misconfigured database reversed to clinicworkflow.org, a domain that was first registered on November 13, 2016 and that is linked to Emory Brain Health Center.

The MacKeeper team have have been disclosing leaks due to misconfigured MongoDB installations since last year, and this was just another one it seemed. But on January 3, when the research team went back to the IP address to review and analyze the exposed data and then notify the entity, they found that in the interim, the database had been stolen by Harak1r1, who left the now well-publicized ransom message demanding .2 BTC.

The database was gone and in its place, a ransom demand. Courtesy of MacKeeper Security Research Center.

According to information the MacKeeper security research team shared with DataBreaches.net, the files had included:

  • 6,772 records in ‘Clinicworkflow’ with medical record number, address, birth date, name, last name
  • 31,482 records in ‘Orthopaedics’ with first name, last name, medical record number, address, email address
  • 157,705 records in ‘Orthopaedics2’ with cellphone number, first name, last name, address, email address; and
  • 168,354 records in ‘Orthoworkflow’ with cellphone, first name, last name, birth date, address, email address

MacKeeper informs DataBreaches.net that many of the same patients’ records were in the last two folders and that they do not represent over 300,000 unique patients. They estimated the number of unique patients at about 200,000.

Information and screenshots provided to DataBreaches.net also revealed timestamps in the database from 2015-2016. An “admins” folder reportedly contained email addresses of emoryhealthcare.org employees.

But was this database under Emory Healthcare’s direct control, or was it under a contractor or business associate’s control?

Yesterday, DataBreaches.net sent inquiries to both Emory Healthcare and to the registrant for the clinicworkflow.org domain, but neither responded to the multiple inquiries by the time of this publication. DataBreaches.net also attempted to contact Harak1r1, but the email bounced back as “user unknown.”

The IP address is not one of the IP addresses that had previously received any notification or warnings, Victor Gevers tells us.

This post will be updated if more information becomes available. In the meantime, do see MacKeeper’s blog post about this incident, and thanks to them for making this site aware of this incident.


On January 10, this site received the following statement from Emory:

Emory Healthcare has learned about an incident of unauthorized access to a database that a few of our clinics use to expedite patient flow during appointments. The database is hosted by a third party and is not an internal Emory or Emory Healthcare database. The database contained limited information for approximately 90,000 patients; it did not include social security numbers, financial information, or patient medical records, and the incident did not impact medical care. This temporary security intrusion was identified and immediately rectified. Emory is continuing to investigate this situation and will notify involved patients.

In follow-up communications with them on Jan. 10 and 11, a spokesperson informed DataBreaches.net that they had not paid the ransom demand, and that they had been able to restore the database from backup.

Emory did not respond to a direct question asking them to confirm or deny that clinicworkflow.org was the responsible third-party, and clinicworkflow never responded to this site’s inquiry.

When asked whether Emory had determined whether the data had been exfiltrated or just deleted, the spokesperson said that they were still investigating the incident, but had no further information to share at this time.


  • As of this morning, more than 114TB of data have been wiped out by MongoDB ransomware attacks. The number of attacked databases, as of 20 hours ago, was more than 32,000.
  • A newly observed variant of the ransom note threatens victims that if they don’t pay up, their data will be dumped publicly and everyone will know about their security failure.
  • Researchers still have seen no evidence, however, that any of these attackers is really exfiltrating and storing all data.
  • Source code for the ransomware used by one of the more prolific attackers, Kraken0, has been put up for sale by someone claiming to be Kraken0.

As to these databases storing medical or patient data, Victor Gevers reminded me that he had tried to call attention to that problem last year:

Since December, 2015, DataBreaches.net has reported on five such incidents, including the current report involving Emory Healthcare.

At some point, either HHSOCR or FTC – or class action lawyers – will take a look at any future incidents and say, “Hey, this problem has been known and publicized for years now. This is unreasonable security on your part – or contributory negligence.” Can’t we just avoid all that by getting entities to update their platforms and check to see that port 27017 is closed and that adequate authentication is required to access the database? Of course, attackers will likely go on to greener pastures (like unsecured Rsync devices or clones), and we need to do massive blasts and alerts NOW to avoid more of this type of thing.

Update: This incident was reported to HHS as impacting 79,930. You can read their notification letter here. The third-party application was identified as Waits & Delays.

About the author: Dissent

Comments are closed.