The healthcare industry deals with immense amounts of sensitive data from patients and any operational disruptions can be a matter of life and death. Because of that, the sector has become a hotspot for threat actors to carry out targeted cyberattacks.
Ransomware attacks have been increasing in numbers within the healthcare sector, resulting in financial losses. We see them happening all over the world. For example, the data breach on MCG Health in the United States exposed 1.1 million patients’ data, and the ransomware attack on the Eye and Retina Surgeons Clinic in Singapore compromised more than 73 thousand patients’ data.
The risks factors are just increasing: the pandemic that has shone a spotlight at the sector, a generally aging population with specialized healthcare needs,, and increasing amount of medical devices with network connectivity, all means that there are more cybercriminals in directing into this lucrative sector. As such, security teams working in these industry must work around the clock to remain a step ahead of any threats.
In this blog, we’ll be focusing on a vulnerability DICOM, used in imaging systems (i.e. X-Rays and CT Scans).
The problem with DICOM
DICOM (Digital Imaging and Communication in medicine) is the standardized format for CT scan or X-ray metadata to ensure interoperability between different imaging systems and software. These DICOM files would be stored in the Picture Archiving and Communication Software (PACS) server where they would be stored, retrieved, and managed.
The radiologist or doctor would then access these images and metadata through a specialized software called a DICOM viewer, which allows them to view and manipulate images.
However, in recent times, Cylera had discovered a design flaw in the DICOM standard.
DICOM Design Flaw
With reference to the diagram above, there is a small section at the beginning of the header called the preamble which is 128 bytes long. The preamble is used to access the images and other related data in the DICOM files through either a non-DICOM or DICOM software.
The problem lies in the possibility of inserting a piece of malicious code that is 128 bytes or less into the preamble of the DICOM file. On the outside, the DICOM file appears to be executable with no alarming characteristics. However, on the inside, the malicious code is there, concealing itself from detection. As such, the malicious code is launched the moment the file is opened by the DICOM viewer.
The DICOM images can maintain their .dicm extension while the malware executes. When doctor or radiologists open the file, the original DICOM and clinical information will be displayed, along with child process spawning at the backend. That is how the malware would be unleashed into the PACS and compromise it. Below is a demonstration by Cylera on how the DICOM file extension can be renamed into a .exe extension file to launch a code.
So how does the malicious code end up in DICOM files?
Firstly, it could be through phishing. Social engineered emails can be sent to hospital staff, containing a bat file, affecting the victim’s computer upon opening. Also known as a batch file, a bat file contains a series of commands which are executed in sequence. When a user clicks on the phishing link, the bat files are downloaded and executed by them. These bat files may download additional DICM extensions files, execute the malware, and open the DICOM file. The victim may never notice that there was a malware embedded inside the DICOM file once executed or transferred over the network.
A second way is is through the intrusion of hospital infrastructure by uploading the corrupted DICOM images to the PACS server using the DICOM protocol. According to DICOM protocol, DICOM files are to be uploaded into the PACS server and transferred over the network. As a result, the affected file would corrupt other DICOM files while being transferred. The DICOM Protocol can also be used in a multi-stage attack after the initial compromise.
Can Antivirus or EDR help?
At this point, the first thought that may pop up in your mind is: Does my Antivirus or EDR software help? No, it is not ideal.
There are many compliance regulations in the industry, mainly set to protect sensitive information. In this case, medical device manufacturers or health organizations often configure their anti-malware or EDR software to ignore medical imagery and files that contain protected health information. This is because there is a possibility that the antivirus may delete a DICOM file over a false positive, causing a loss of patient data.
Security teams also are unable to upload suspected malware to common cloud-based analysers without sacrificing the patient’s data in the image. In addition, they cannot delete affected DICOM files without running the risk of deleting HIPPA-protected patient information.
Hence, Antivirus or EDR software is not ideal to tackle this issue.
How can LogRhythm help?
In this section, you will be able to mitigate DICOM-based cyberattacks by improving your incident response time using LogRhythm SIEM. For the sake of demonstration, we will be utilizing Microdicom viewer and Orthanc for PACS which are both open source.
In this scenario, we want to detect any suspicious processes which opens the DICOM files. As such, we will create an observed rule looking for processes like conhost or cmd when the DICOM file is opened. We will be utilizing Microsoft Sysmon as a log source to audit process or file creation. You may learn how to enable auditing for process creation here.
LogRhythm SIEM will observe and analyze the logs from Microsoft Sysmon in real time, searching for anything out of the ordinary. An alarm will be triggered with a high-risk score when SIEM detects the DICOM file spawning from a potentially suspicious parent process. However, something to note is that the alert being triggered does not indicate an attack or breach. It is still important to review the alert and subsequent activity for lateral movement.
Below is the breakdown of the extracted metadata which shows conhost.exe as a parent process that opened the DICOM file (i.e. pedicom-cylera.dcm).
Sometimes, when a DICOM file is opened by a DICOM viewer, it will spawn suspicious child processes. A DICOM viewer will ignore the preamble bytes as it only observes the DICM string and process the DICOM content. If the DICOM viewer is not sanitized and the input of the preamble byte is read as an executable or as a script, it could have a severe impact on the security of the viewer and the system it is running.
In this scenario, we will enable auditing for process creation to track any malware activity from the DICOM viewer.
To start things off, create an observed rule looking for suspicious child processes (e.g. PowerShell, cmd, bitsadmin) getting spawned from your DICOM viewer.
If the DICOM viewer spawns suspicious child processes, LogRhythm SIEM will trigger an alarm with a high-risk score. Once again, review the alert and associated activity for signs of lateral movement.
Below is the alarm drill down with the extracted metadata. As you can see, by opening the DICOM viewer (i.e. mdicom.exe), it had spawned a suspicious child process (i.e. powershell.exe).
With these rules and alerts set in place, you’ll now be alerted whenever suspicious parent or child processes are spawned by DICOM files, allowing you to rapidly respond to any threats abusing this vulnerability.
With the huge amount of sensitive data the healthcare sector processes, it’s an attractive target for cybercriminals. Being subjected to regulatory requirements such as HIPAA and GDPR mandating strict security controls and data protection measures also requires security teams to manage risks creatively, as typical tools may not be an option. LogRhythm, with our experience in the healthcare sector, can help improve incident response time by providing real-time alerts and automating incident response. Schedule a demo with us today to learn how we can help you secure your organization!
The post Gaining X-Ray Vision: Preventing healthcare cyberattacks with LogRhythm appeared first on LogRhythm.
from LogRhythm https://bit.ly/3UHTSgY
Post a Comment