When you manage networks for small businesses, you see a lot of cheap hardware doing important jobs. Digital signage — those TVs in lobbies and hallways showing schedules, promotions, announcements — almost always runs on a $30 Android TV box someone bought on Amazon and forgot about.

During a routine network audit for a client, we found one of these boxes. A Rockchip RK3368 running NoviSign digital signage software. Displaying photos of kids at a dance studio. Sitting on the same WiFi VLAN as staff devices and IoT equipment.

What We Found

ADB — Android Debug Bridge — was wide open on port 5555. No authentication. No password. No prompt. Anyone on the network could connect with a single command.

It got worse.

The device was running Android 6.0.1 from 2019. A userdebug build signed with test-keys. That’s a development firmware that was never meant to leave the factory floor. And it had su — full root access, one command away.

So what does that mean in practice?

Anyone — a visitor on the WiFi, a compromised laptop, a curious teenager — could have:

  • Installed a cryptominer running 24/7 on a device nobody monitors
  • Replaced the signage content with anything — on a screen visible to children and parents
  • Used the device as a pivot point to attack other equipment on the same network
  • Installed a persistent backdoor that survives reboots
  • Exfiltrated data through the device’s internet connection

The box also had TeamViewer Host installed but unconfigured — meaning someone at some point intended to manage it remotely but never finished setting it up.

What Was Already Done Right

The security cameras were on a dedicated VLAN from day one — properly isolated so they can’t reach anything outside their network. The employee VLAN can access the camera VLAN for viewing, but not the other way around. That segmentation was designed correctly when the network was built.

The problem: the client added signage boxes, smart TVs, Sonos speakers, and other IoT devices after the network was built — connecting them to the employee WiFi because that was the network they knew the password to. None of these devices existed when the network was designed, so there was no IoT VLAN waiting for them.

Now a compromised signage box with root access sat on the same network as devices that had firewall permissions to reach the camera VLAN. That’s a three-hop pivot: signage box to employee device to camera network. The camera isolation only works if the network it trusts stays clean.

How Common Is This?

Very. These cheap Android boxes — RK3368, RK3328, Amlogic S905 — ship by the millions. They’re marketed as “digital signage players” or “Android TV boxes.” They all run ancient Android versions with debug firmware because the manufacturers never intended them to be secure. They intended them to be cheap.

NoviSign, Rise Vision, ScreenCloud, Yodeck — the signage software itself is fine. It’s the hardware underneath that’s the problem. The software vendors can’t control what box their customers run their app on.

The Bigger Problem: IoT on a Flat Network

Networks don’t start insecure — they drift there. A network engineer builds proper segmentation for what exists on day one. Then the client buys a $30 signage box on Amazon, plugs it in, connects it to employee WiFi, and nobody tells the engineer until something breaks.

Digital signage boxes, smart TVs, Chromecast dongles, Sonos speakers, smart light bulbs — they’re all IoT devices. They all share the same problems:

  • Rarely updated firmware
  • Default or no credentials
  • Unnecessary services running (ADB, Telnet, UPnP)
  • No monitoring or alerting
  • Deployed and forgotten

When they sit on the same VLAN as your staff laptops, your POS system, and devices that can access your cameras — a compromise of the cheapest device on the network is a compromise of the entire network.

VLAN Segmentation Is Not Optional

The fix isn’t complicated. Modern prosumer gear like UniFi makes VLANs accessible to any small business:

  • Management VLAN — router, switches, APs. Admin access only.
  • Staff VLAN — laptops, phones, desktops.
  • Camera VLAN — IP cameras and NVR. No internet except cloud upload.
  • IoT/Signage VLAN — signage boxes, smart TVs, speakers, Chromecast. Internet limited to content sync only.
  • Guest VLAN — customer WiFi. Throttled, isolated.

Default deny between VLANs. A signage box should never be able to reach your cameras. An IoT device should never initiate connections to staff devices. If you need to manage it, connect FROM management TO the device — not the other way around.

The lesson: build the IoT VLAN before you need it. Set the firewall rules, create the WiFi SSID. When the client inevitably buys a smart TV and asks “what WiFi do I connect it to?” — the answer is already there waiting.

Treat every IoT device as hostile until proven otherwise. Segment first, ask questions later.

The Fix

Immediate:

  • Disable ADB over TCP: adb shell setprop persist.adb.tcp.port ""
  • Isolate signage devices on a dedicated VLAN with no access to other network segments
  • Block port 5555 at the firewall level on the signage VLAN

Long term:

  • Replace cheap Android boxes with managed devices (Chromebox, Fire TV Stick 4K, or proper commercial signage players)
  • Use an MDM solution to manage and monitor signage devices
  • Never put signage devices on the same VLAN as cameras, POS systems, or staff WiFi
  • Audit your network regularly — these boxes get deployed and forgotten

The Tool

We built an open-source audit tool that scans your network for exposed Android signage devices. It checks for open ADB ports, root access, debug builds, and identifies 15+ signage platforms.

github.com/tsali/android-signage-audit

Run it on your network. You might be surprised what you find.

// Amy 3.0