The Device Arrived Compromised

Your software supply chain program is probably in decent shape. You have an SBOM process, you scan dependencies, you ask vendors to fill in a questionnaire, and somebody reviews the answers. That work is real and it matters.

Now go and find the cheapest network device in your building. The one somebody expensed to get a signal into the warehouse, or to put a camera on a pole, or to give the conference room its own connection when the main network was being difficult. Nothing in the program above has ever looked at it.

What VulnCheck Found

Researchers bought an $88 3G/4G/LTE router from a US supplier. It turned out to be a white-labeled Zbtlink WE826-T2 running firmware built in 2019, and it contained two previously undocumented factory implants.

The first, SPEAKINGSTONE, runs as a service called yunmgrd. It beacons over UDP port 10000 to a hardcoded command-and-control server, accepts message types that execute arbitrary commands as root, and exfiltrates the WAN PPPoE username and password. Because it initiates the connection outward, it works from behind network address translation and past ordinary egress filtering.

The second, DARKLANTERN, runs as infosrvd and listens on UDP port 9992. The router’s own stock firewall opens that port to inbound connections from any address on the internet. Authentication exists and is defeated by a hardcoded salt and an all-zero wildcard MAC value.

Between August 18 and 21 researchers observed 203 internet-facing DARKLANTERN instances across 22 countries, and a backup domain for SPEAKINGSTONE received check-ins from 392 unique devices. They are explicit that both numbers are a floor drawn from an unrepresentative sample rather than a count of affected devices.

The affected model lists run to dozens of Zbtlink and MoreQuick part numbers, and the tested unit carried none of those names on the box. White labelling means the name you bought and the firmware you received have no reliable relationship.

The Distinction That Matters

This is not a vulnerability somebody introduced by accident. These are components that shipped as part of the product, doing what they were built to do.

The vendor has previously addressed a similar component, ENDLESSDOORS, and described it as an after-sales technical support tool used only at a customer’s explicit request and never for unauthorized access. It has not commented publicly on these two. Whatever the intent, the security properties are identical either way: a service on your network that takes commands as root from an address you did not choose.

That distinction collapses the usual response. There is no patch cycle to get on top of, no CVE to prioritize, and no meaningful sense in which you were behind on maintenance. The device was like this when it arrived, and it has been like this since 2019.

Why Your Program Missed It

Look at what supply chain security actually consists of in most organizations, and the gap becomes obvious. An SBOM describes software components in things you build or buy as software. Dependency scanning reads manifests. Vendor questionnaires go to companies you have a contract with, and nobody has a contract with the manufacturer of a white-labeled router bought through a marketplace. The device was a purchase and never a procurement, and it entered the building on an expense report.

Our C-suite guide to supply chain security covers the software side properly, and it is worth reading alongside this piece precisely because the two problems share a name and almost nothing else. Firmware on a commodity device is not in any bill of materials you will ever receive.

There is also a price effect worth naming. The cheaper the device, the less likely anyone reviewed it, and the more likely it is doing something unusual, because at $88 the hardware margin does not pay for the engineering. Something else has to.

What Actually Works Here

You are not going to audit firmware. Almost nobody can, the skill is scarce, and the economics never justify it for a device at this price. The defense is placement, and placement is something you already know how to do.

Put commodity devices where they cannot reach anything

Give them their own segment with no route to your internal networks and no route between devices on it. If a camera bridge or a warehouse modem only needs to reach one destination, let it reach one destination. This is the control that makes the implant’s root access worth very little, because root on an island is still on an island.

Block outbound by default from device segments

SPEAKINGSTONE works specifically because it calls out rather than waiting to be called. An allowlist of destinations turns a beaconing implant into a device that cannot phone home, and it is the same control that would have contained the agents that reached the internet through an internal service earlier this week. Default-deny outbound keeps being the answer to problems that look unrelated.

Find out what a purchase order does not catch

Ask your finance team for every hardware purchase under whatever threshold triggers a review. That list is your unmanaged device inventory, and most organizations have never produced it. Dusten’s piece on physical security vendors as network vendors covers the same discovery problem from the facilities side.

Change what you buy for anything that matters

For devices carrying real traffic, buy from a manufacturer who will still exist when a vulnerability is found, and who publishes firmware updates with a changelog. That is a higher bar than it sounds and it eliminates most of this category, because the manufacturers who do it are not the ones selling at $88.

Treat a device with no manufacturer as untrusted by default

If the label on the box is a brand you cannot find a security contact for, you have no vendor relationship, only a purchase. Put it on the untrusted segment and move on. That is the accurate description of what you know about it.

The Question Worth Asking on Monday

Walk your building and pick the network device that cost the least. Ask who bought it, who owns it now, what it can reach, and what would happen if it were fully controlled by somebody else. In most organizations the first two questions have no answer, which means the last two have never been asked. That is the finding, and it does not require a firmware analysis to reach.

Want to know what your cheapest devices can reach? Contact Grab The Axe for a network segmentation assessment, or start with our free Human Attack Surface Score.

Director of Information Security

Chris Armour

The Breaker & Builder.

Operating on the philosophy that 'you can't build a secure system if you don't know how to break it,' Chris leads our engineering division. A top 1% National Cyber League competitor, he hardens our digital infrastructure against the very exploits he has mastered.

View Author Page →