Healthcare organizations are a lucrative target for bad actors due to their unique position; they store sensitive patient information, provide a critical service to the public, and typically do not have massive cybersecurity budgets. This makes the healthcare industry particularly susceptible to attacks that threaten to exfiltrate information, disruption operations, or both.
In fact, according to Check Point Research, the healthcare sector experienced a significant rise in attacks with an average of 1,684 attacks per week in Q1 of 2023, marking a substantial year-over-year increase of 22%. This increasing number shows how cybercriminals are pinning a target on many healthcare organizations, focusing their efforts to siege their operations and causing irreparable damage.
Previously, we covered how DICOM files can be exploited to launch malicious code when executed. In this blog post, we will be going through the HL7 , how it can be exploited and how LogRhythm can help you mitigate these cyberattacks.
What is HL7?
Imagine you’re visiting the hospital for a doctor’s appointment. After arriving at the hospital, you fill out a form, providing confidential information such as your name, date of birth, health information, address, allergies, etc. The staff would key this information into the hospital information system (HIS).
After meeting the doctor, they might order a series of X-Rays, CT scans, blood tests and other tests for further examination. Instead of writing notes and handing it to the nurse, your doctor uses HL7. HL7 is a standard format for exchanging healthcare information electronically. This information will be entered into the HIS for other medical staff like radiologists to view.
Health Level 7 or more commonly known as HL7, is a collection of standards for transferring clinical and administrative data between hospital information systems, allowing a seamless experience every time you visit the hospital. It is designed to work with all hospital systems in patient care (i.e. between radiology information systems and hospital information systems).
How Does HL7 Work?
When you send a message using HL7, it is broken down into a series of segments. Each segment contains a specific piece of information, such as the patient’s name, date of birth, or medical record number. The segments are then arranged in a specific order to create a message.
The messages are then transmitted over a network, such as the internet. When the messages arrive at the destination, they are reassembled into their original form. The receiving system then interprets the data and takes the appropriate action.
HL7 is a complex standard, but it is essential for the efficient exchange of healthcare information. It is used by millions of people every day to improve the quality of care.
HL7 Interface Engine
Acting as a translator, the HL7 interface engine allows disparate systems in a hospital environment speak a similar language. During a hospital visit, there will be different messages of different types sent through these systems for every event you encounter.
Let’s say a patient moves to a different room. A HL7 admissions, discharge, and transfer (ADT) message will be sent from one system to another that needs the updated information.
Similarly, if someone orders a test or drug, an order (ORM) message is triggered.
Sending test results or telemetry data? An observation result (ORU) message is sent.
All these messages are typically sent behind-the-scenes, and you may not even be aware that these messages are being transmitted.
In most cases, a single HL7 message will be relayed to the interface engine for them to be transformed and forwarded to numerous outlying systems to sync the data.
Breaking Down a HL7 Message
Now that we understand how the HL7 protocol works, let’s dive into the messages. HL7 messages are divided into segments with a Carriage return, and these segments are then divided into fields with pipes (i.e. |||). Now, let us break down a sample HL7 message.
Pay close attention to the highlighted parts of the message. If you have noticed by now, the highlighted fields are pieces of information from the patient named Mickey Mouse. Below is a table with the extracted fields from the sample HL7 message.
The message type is critical for filtering out messages which are not relevant to the application. Below is a table of message headers and their corresponding descriptions.
Now, if we look at the extracted sample message below, we can identify the message type to be ADT, which is related to admission, discharge, and transfer for patient administration.
Additionally, if we take a closer look, the message header includes ‘^A01‘ which specifies that the patient is currently undergoing the admission process. Now that we understand how the HL7 protocol works, we’ll be discussing two types of attacks that cybercriminals could potentially carry out and providing a solution for both methods with our technologies.
Attack 1: Man-in-the-Middle (MITM) Attacks
As the name suggests, a man-in-the-middle attack occurs when an attacker intercepts HL7 messages. This can be done by gaining access to the network or communication channel for transmitting HL7 messages.
Once they have access, the attacker can steal sensitive patient health information and modify the messages. This type of attack can lead to devastating consequences such as a breach in patient safety and confidentiality, as well as a hit to the healthcare organization’s reputation.
MITM attacks often use Address Resolution Protocol (ARP) spoofing as a technique to intercept and manipulate network traffic.
For some context, ARP is a critical network communication protocol used extensively in local area networks.
ARP spoofing would be easy for those with the necessary technical knowledge and tools. It involves sending fake ARP messages to a network, tricking hospital devices into sending their data packets to the attacker instead of the intended recipient. From there, the attacker can modify network traffic.
Below is a visualisation of the process.
With reference to the above image, the attacker (192.168.0.117 | 00-0c-29-28-c0-91) could send fake ARP messages to other devices on the network. These messages would associate the attacker’s MAC address with the IP address of one of the legitimate devices, such as the Windows interface system (192.168.0.141 | 00-0C-29-E8-C9-C5) or the Linux interface system (192.168.0.246 | 00-0C-29-66-CC-E2).
Once associated to either device’s IP address, the attacker can intercept and manipulate traffic between the Windows and Linux interface systems, allowing them to steal sensitive information or modify exchanged data.
So how does an attacker conduct ARP spoofing?
All they need is Ettercap.
Ettercap is a common tool used in ARP spoofing. It improves the legibility of the HL7 message exchange by identifying the original message [on the left] and its corresponding ACK [on the right].
How can LogRhythm help you with detecting MITM attacks?
You can prevent such attacks by utilizing LogRhythm Network Monitor (formerly known as NetMon) to capture and analyze ARP packets. This way, LogRhythm Network Monitor can detect and alert potential ARP spoofing attacks or other suspicious activity on the network.
Moreover, it has a built-in integration with the LogRhythm SIEM platform, which enables automated ingestion and correlation of network traffic data with other data sources.
Starting off, you’ll need to create a Deep Packet Analytics (DPA) rule in LogRhythm NetMon which can extract the following: Source and Destination MAC addresses, Source and Destination IP addresses, and ARP opcode 2. In the context of the Address Resolution Protocol, opcode 2 refers to the ARP reply message.
With this rule in place, when a device sends an ARP request to retrieve the MAC address of a specific IP address on the network, the device with the matching IP address responds with its own MAC address.
When creating a DPA rule on packets, the extracted metadata will be written as a log:
2023/04/10 14:21:06 9592881146 INFO [LuaFunctions.cpp->InfoLog:290] ” Lua [[string “function arp_spoofing_opcodes(msg, packet)…”]:1] ARP opcode: 0002, Source MAC address: 00:0C:29:AE:78:50, Destination MAC address: B0:BE:76:77:D0:20, Source IP address: 192.168.0.222, Destination IP address: 192.168.0.1”
It will be stored in the following location: /var/log/probe/ProbeReader.log
Next, let’s ship these logs to LogRhythm Security Analytics using the same syslog stream to forward Netmon Metadata.
Here, we want to update the /etc/rsyslog.conf file with the necessary configuration changes. This file is the main configuration file for rsyslog on CentOS. However, it is important to note that we should not directly modify the /etc/rsyslog.conf file, as it is managed by the system package manager. Instead, create a separate file in the /etc/rsyslog.d/ directory with a .conf extension to add your custom configuration.
For example, create a file named /etc/rsyslog.d/probe-reader.conf and add the configuration block below. Then, restart rsyslog for the changes to take effect:
Finally, let’s create an MPE rule using the MPE rule builder to parse the given metadata and associate it with the LogRhythm Network Monitor log source.
^.*?ARP opcode:\s(?<object>.*?)\sSource MAC address: (?<smac>.*?)\,\sDestination MAC address:(?<dmac>.*?)\, Source IP address: (?<sip>.*?)\,\sDestination IP address: (?<dip>.*?)”
This rule block will trigger if any MAC address is found to be associated with more than one IP address, an alert is raised indicating the MAC address spoofing. Below is an example of the rule block.
Let’s say an attacker tries to intercept the communication between two systems. When this happens, their MAC Address will be associated with multiple IP addresses. The LogRhythm SIEM picks up on this and sends out a high-risk alert as shown below.
With LogRhythm SIEM, you can look at the breakdown of the extracted metadata which shows the IP addresses associated with the attacker’s MAC address as shown below.
Attack 2: Unauthorized Senders
Another method malicious actors can resort to is exploiting the minimum lower layer protocol (MLLP) which is a framing mechanism to standardize HL7 messages for transmission over TCP/IP networks. In this scenario, the IP Address and TCP port, and some knowledge of the HL7 message format is enough for an attacker to cause damage by sending additional unauthorized messages.
Moreover, it is easy to modify these messages. In fact, a text editor is all you need to make any changes. Following the example below, with just a few keystrokes, you can erase the patient’s severe allergic reaction to penicillin.
How can LogRhythm help you with detecting unauthorized senders?
When it comes to this scenario, LogRhythm Network Monitor can help you capture MLLP traffic and extract metadata from it, enabling you to gain deeper insights into your data exchange environment. You can extract metadata from the protocol headers, such as the source and destination IP addresses, MAC address, message length, and the checksum. By doing so, we can analyze them to identify patterns and anomalies in the MLLP traffic such as an unknown sender attempting to access the HL7 interface.
To detect such actions, let’s create a network traffic and behavior analytics (NTBA) rule that triggers an alarm when HL7 traffic is being sent to or received from an unknown host in the network. Note that an unknown host could indicate a compromised host or a misconfiguration in the network.
Upon detecting HL7 traffic and identifying that the source/destination IP address is not present in the Profile or list of known hosts, the SIEM will trigger an alarm with a high-risk score.
In the extracted metadata below, you can see the unknown host in the network is trying to access the HL7 interface on port 6661.
Secure Your Data with LogRhythm today
HL7 is a crucial component in your organizations’ communication channel across your systems. When taken advantage of through MITM attacks or communication with an unknown host, it could pose a serious threat to patient safety and data security.
To combat against these attacks, we’ve highlighted how LogRhythm can help you secure your day-to-day operations through our network monitoring and SIEM capabilities. If you’re keen to know more about how we can help secure your healthcare organisation with ease, schedule a meeting with us today!