Attacks/Breaches

2/8/2018
11:15 AM
50%
50%

Tennessee Hospital Hit With Cryptocurrency Mining Malware

Decatur County General Hospital is notifying 24,000 patients of cryptocurrency mining software on its EMR system.

Decatur County General Hospital (DCGH) in Parsons, Tennessee, recently discovered cryptocurrency mining malware on its its Electronic Medical Record (EMR) server. The hospital began informing 24,000 patients of the attack on January 26.

On November 27, 2017, the hospital received a security incident report from its EMR system vendor, which said unauthorized software, designed to mine cryptocurrency, had been installed on the server supported by the vendor. An ongoing investigation has indicated an unauthorized attacker accessed the server with the EMR system and injected the software.

The hospital's EMR server contained data including patient names, addresses, birthdates, and social security numbers, as well as diagnosis and treatment data. There is no evidence either type of data was taken or viewed, and so far it doesn't seem data theft was the attacker's goal. However, the hospital cannot definitively prove data was not compromised and is therefore notifying patients.

DCGH has not named the EMR system vendor and is offering patients the myTrueIdentity online credit monitoring service for one year. Read more details here.

Dark Reading's Quick Hits delivers a brief synopsis and summary of the significance of breaking news events. For more information from the original source of the news item, please follow the link provided in this article. View Full Bio

Comment  | 
Print  | 
More Insights
Comments
Threaded  |  Newest First  |  Oldest First
tmerrem945
100%
0%
tmerrem945,
User Rank: Apprentice
2/8/2018 | 1:30:08 PM
you'd assume the EMR data is encrypted
It troubles me that the hospital cannot confirm if the data was taken or viewed.  Had the data been encrypted, then they can be certain the intruder wasn't able to view the information.  
BrianN060
50%
50%
BrianN060,
User Rank: Ninja
2/8/2018 | 5:09:46 PM
Re: you'd assume the EMR data is encrypted
@tmerrem945: sensitive data that leaves a private network should be encrypted.  Data kept within a private network might be encrypted - but anyone (real person or system/application process), that needs access to those data values, has to have the means to decrypt that data. 

So, if an attacker has acquired the necessary credentials,  they'll have the access privileges that go with those credentials. 

Post breech forensics might be able to determine if the attacker used stolen credentials - but that can take time; and breech notification requirements don't always leave enough time for a complete investigation.  
Want Your Daughter to Succeed in Cyber? Call Her John
John De Santis, CEO, HyTrust,  5/16/2018
New Mexico Man Sentenced on DDoS, Gun Charges
Dark Reading Staff 5/18/2018
Register for Dark Reading Newsletters
White Papers
Video
Cartoon Contest
Write a Caption, Win a Starbucks Card! Click Here
Latest Comment: This comment is waiting for review by our moderators.
Current Issue
Flash Poll
[Strategic Security Report] Navigating the Threat Intelligence Maze
[Strategic Security Report] Navigating the Threat Intelligence Maze
Most enterprises are using threat intel services, but many are still figuring out how to use the data they're collecting. In this Dark Reading survey we give you a look at what they're doing today - and where they hope to go.
Twitter Feed
Dark Reading - Bug Report
Bug Report
Enterprise Vulnerabilities
From DHS/US-CERT's National Vulnerability Database
CVE-2018-11354
PUBLISHED: 2018-05-22
In Wireshark 2.6.0, the IEEE 1905.1a dissector could crash. This was addressed in epan/dissectors/packet-ieee1905.c by making a certain correction to string handling.
CVE-2018-11355
PUBLISHED: 2018-05-22
In Wireshark 2.6.0, the RTCP dissector could crash. This was addressed in epan/dissectors/packet-rtcp.c by avoiding a buffer overflow for packet status chunks.
CVE-2018-11356
PUBLISHED: 2018-05-22
In Wireshark 2.6.0, 2.4.0 to 2.4.6, and 2.2.0 to 2.2.14, the DNS dissector could crash. This was addressed in epan/dissectors/packet-dns.c by avoiding a NULL pointer dereference for an empty name in an SRV record.
CVE-2018-11357
PUBLISHED: 2018-05-22
In Wireshark 2.6.0, 2.4.0 to 2.4.6, and 2.2.0 to 2.2.14, the LTP dissector and other dissectors could consume excessive memory. This was addressed in epan/tvbuff.c by rejecting negative lengths.
CVE-2018-11358
PUBLISHED: 2018-05-22
In Wireshark 2.6.0, 2.4.0 to 2.4.6, and 2.2.0 to 2.2.14, the Q.931 dissector could crash. This was addressed in epan/dissectors/packet-q931.c by avoiding a use-after-free after a malformed packet prevented certain cleanup.