Two stories landed within days of each other this month, and on the surface they have nothing to do with the average development team. Kaspersky researchers published an analysis of malware infecting Android-based automotive head units. Slovakia’s national security authority announced it had found a backdoor in traffic speed cameras it was about to install on public roads. Neither involves a web application, a cloud provider or a JavaScript package.
Read them together and they describe the same failure, one your organisation almost certainly shares. Both were supply chain attacks against devices sitting below the layer anybody audits. Every team we work with can produce a dependency graph for its application in ninety seconds. Almost none can tell you what firmware runs on the screen in reception, who built it, when it last received a patch, or what it talks to when nobody is looking.
TL;DR
- Malware named JarService reached DoFun Android car head units through TWCore, the manufacturer’s own update application, which took install commands from an MQTT broker and would silently install apps that were never on the device.
- Slovakia’s NBU found 279 NERO R-ONE traffic cameras were rebadged Russian CORDON PRO.M units bought via a Cyprus shell company, with a backdoor granting shell access by SMS from hardcoded numbers, SecureBoot disabled and unauthenticated live streams.
- SBOMs, dependency scanning and CI attestation all stop at the operating system boundary. Below it there is usually no version number, no advisory feed and no way to verify what shipped.
- The practical controls are network controls: dedicated VLANs, default-deny egress, DNS logging, and treating every appliance as untrusted.
- Procurement is a security control. End-of-support dates, update signing and the real identity of the manufacturer belong in the purchase contract.
The update channel was the attack
The head unit case is the more instructive of the two, because nothing about it required a vulnerability in the usual sense. DoFun head units, the Android devices that handle a car’s multimedia and some of its vehicle controls, ship with a system application called TWCore whose job is to manage software updates. TWCore receives installation instructions as MQTT messages from a remote broker. When a message arrived with an installNotExists flag set to true, TWCore would install an application that had never been on the device, without asking anybody.
That is not a bug in the traditional sense. It is a feature working exactly as designed, pointed at a broker somebody else controlled. What arrived was a three-stage payload ending in a module that turned the vehicle into a node in a reverse proxy botnet, intercepting HTTP requests and running advertising fraud. Researchers catalogued seven variants of the final stage, which tells you this was an operated campaign rather than a one-off.
The lesson generalises well beyond cars. Any device with an automatic update mechanism has, by definition, a permanent authorised channel for remote code execution, and that channel is the most valuable thing on the device. Secured properly, with signed packages and a verified chain of trust, it is a strength. Secured by trusting whoever is on the other end of an MQTT connection, it is a backdoor with a support contract.
You may not know who built your hardware
The Slovak case attacks a different assumption: that you know what you bought. The Interior Ministry purchased 279 NERO R-ONE high-speed traffic cameras as part of a thirty million euro EU-funded programme. The NBU’s investigation concluded the devices were rebadged CORDON PRO.M units manufactured by a St Petersburg firm, sold through a Cyprus intermediary carrying fabricated certifications.
Inside, investigators found a mechanism granting shell and network access to the device in response to an SMS from a hardcoded list of Russian phone numbers. They also documented SecureBoot deliberately disabled, vulnerabilities in the management web portal, and live camera streams reachable with no authentication at all. Deployment has been paused pending independent assessment.
Most organisations are not buying national infrastructure, and that is not the point. The point is that a brand on a bezel tells you nothing about who wrote the code inside, and rebadging is the norm rather than the exception across the commodity device market. Access control panels, digital signage players, network video recorders, EV chargers, conference room systems: a very large share are white-labelled boards running someone else’s build. When you cannot name the manufacturer, you cannot assess the manufacturer, and you certainly cannot expect an advisory when something goes wrong.
Why the existing playbook does not reach this far
Software supply chain security has matured impressively. Teams generate SBOMs, scan dependencies, pin versions, verify build provenance and watch advisory feeds. All of that infrastructure has one thing in common: it operates on artefacts your build system produces, in ecosystems that publish structured vulnerability data. Firmware offers none of that. There is frequently no meaningful version number, or one that changes without any published changelog. There is no equivalent of npm audit. Most vendors publish no SBOM, and where a CVE does exist it often names a chipset reference design rather than the product you actually bought. The device typically cannot run an agent, so your endpoint tooling never sees it. And the support window, the single most important security property of any appliance, is rarely stated anywhere and frequently ends without announcement.
The honest position is that you cannot audit most of these devices, and you should stop planning as though you can. What you can do is change the assumptions your network makes about them.
Treat every appliance as hostile
The controls that would have limited the damage in both cases are network controls, and they are unglamorous. Put appliances on their own segment, isolated from anything holding data or credentials. Apply default-deny egress and allow only the destinations the device genuinely needs, because a proxy botnet node and a legitimate update client look identical until you check where they connect. Log DNS queries from that segment and actually review them, since novel domains from a device that should speak to three endpoints is one of the cheapest detection signals available. Change default credentials on every device, including the ones with a management interface you have never opened. And where a device offers unauthenticated streams or portals, assume they are reachable and verify from outside.
None of that is new advice. What is new is that treating it as optional now carries a demonstrated cost, and the attackers running these campaigns are commercially motivated rather than exotic.
Procurement is where this actually gets fixed
The most effective security control for an appliance is applied before it arrives. A short set of questions changes what enters the building: who manufactures the device, as opposed to who sells it? What is the committed end-of-support date, in writing? How are updates signed and verified? Is SecureBoot enabled and enforced? What is the disclosure contact? Which network destinations does the device require to function?
Vendors who answer these quickly tend to be the ones worth buying from, and the answers become the basis for the egress rules you write on installation day. Vendors who cannot answer have told you something important. Getting these clauses into a contract is far easier than explaining after an incident why nobody asked.
What to do this quarter
- Build the inventory nobody owns. Every network-connected device that is not a laptop, phone or server: manufacturer, model, firmware version, last update, segment, owner. It takes an afternoon and it will surprise you.
- Segment and apply default-deny egress. If appliances share a network with workstations or servers, that is the highest-value change on this list.
- Turn on DNS logging for that segment and alert on destinations outside the expected set.
- Establish end-of-support dates and diary the replacements. An unsupported appliance is a scheduled problem, not a surprise one.
- Add the security questions to procurement so the next purchase clears a bar rather than inheriting one.
The wider point
Attackers follow the path of least resistance, and application security has genuinely improved. The layer below has not moved nearly as fast, and it is now where the soft targets live. A device that cannot run an agent, does not appear in your asset register, receives no patches and holds a persistent connection to a broker you have never heard of is a far better proposition than your API.
Where this becomes concrete for most businesses is integration work. The moment an automation platform, a building management system or a workflow engine starts talking to physical devices, those devices join your threat model whether anyone acknowledged it or not. We see this constantly in office automation projects: a genuinely useful n8n workflow wired into a dozen appliances, none of which anybody has ever assessed.
At REPTILEHAUS we build the integration and automation layer that connects business systems to physical infrastructure, and the DevOps and network architecture that keeps it defensible: segmented device networks, egress policy that is written down rather than assumed, and monitoring that notices when an appliance starts behaving like a botnet node. If you have devices on your network that nobody can account for, get in touch.
📷 Photo by Alexandre Debiève on Unsplash
