Over the Air Breach
was posted in
Blue Team
by
Peter Bassill
on
February 17, 2024
.
Over the Air Breach
Over the Air Breach
On the 16th of May, a health care provider engaged Hedgehog Security's SOC365 team to provide a breach investigation following the declaration of a major incident and possible breach by the board.
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 tothree 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 torecreate their attack and gain insight into what data was stolen. The diagrambelow 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, containingbank information and payment card data
- 4,394 personal records were accessed and copied
- 822 of those records contained SensitivePersonal Information
- 71 significant data sets of individualscontained excessive information
- 3 core patient delivery services have beenaffected 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:
- What information was at risk?
- Had any information been stolen, and if so, whatinformation?
- How did the breach occur?
To understand what happened, it is best to start in themiddle 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 notconnecting 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 securityadministrator received a single alert from the SIEM alerting to an ExcessiveFile Transfer Size.
May 14 04:17:21 Excessive File Transfer > 2GBnas001.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 spaceutilisation on nas001 was received and the IT team investigated. The TrueNAS device had less than 10% free space and on an 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 has 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 onthe 14th of May. During this time, there was no IT staff on-siteand there were no scheduled backups or scripts that would account for these files being in place.
At this point the client knew the following:
- A system account belonging to a BI functionperformed a large aggregation of information on one of the NAS devices andencrypted the files
- A large quantity of data was transferred from the TrueNAS to a Samsung TV
- There was no evidence to support the informationhad 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 clients 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 look 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 ina 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 anisolated network where we could conduct technical analysis. The first step wasto 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 whatservices on the TV were network-aware:
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 a 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 furthe rinvestigate 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 is 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.
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.
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 privilegeescalation attack against a Smart TV was published by SYNACTIV in 2022.
The getroot file is an encrypted executable binary that isused to run the privilege escalation attack. Although we are not able to readthe 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 tosend files/commands to a remote system.
The ncf file is a script. Looking inside the script provideslight to what has been going on.
None of these files explains how access to obtained in the firstplace.
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 theJavaScript 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.
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. These answer 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 theinteractive 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 “HelloWorld” message. However, there are several JavaScript files that the index.htmlpage 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 accessto 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 thedevices.
The attacker or attackers had successful remote access tothe three devices from the 22nd of April and remain edundetected 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.
Find Peace with SOC365
Defend against Cyber Attacks
Report on Cyber Success
By clicking Sign Up you're confirming that you agree with our Terms and Conditions.
