On August 27, VulnCheck disclosed two undocumented implants in factory firmware for routers made by Shenzhen Zhibotong Electronics, or ZBT. The finding remains urgent because no trustworthy fixed firmware is known, while the published device fingerprints and network signatures now give defenders a concrete way to find exposed hardware.
One implant, DARKLANTERN, listens to the public internet and accepts a crafted packet that reaches a root shell. The other, SPEAKINGSTONE, calls a ZBT-controlled server and accepts unauthenticated instructions to run commands, steal ISP credentials, change DNS settings, or open a reverse SSH tunnel. VulnCheck found both in a white-label cellular router bought from a US supplier.
This is a supply-chain exposure with a careful boundary. The researchers tied ZBT platforms to products sold under several names and found the implants on multiple firmware generations. They did not establish that every ZBT-derived router contains either implant. MOFI, for example, develops custom firmware, and the MOFI image VulnCheck examined was clean.
Two implants share root
The tested device was an $88 Deep Orange 3G/4G/LTE router. Its label, hardware and MAC allocation tied it to ZBT’s WE826 platform. VulnCheck exploited the router’s telnet interface, inspected its 2019 firmware and found two Nim binaries launched by a connectivity watchdog named inetdetect.
DARKLANTERN runs as infosrvd. SPEAKINGSTONE runs as yunmgrd. Both ultimately pass commands to /etc/exec/cmd, but they expose that authority through different network paths.
The distinction determines both exposure and evidence. A public UDP/9992 service is enough to reach DARKLANTERN. SPEAKINGSTONE opens no listener; control depends on reaching its outbound command channel. A firewall can hide the first service from the internet while still allowing the second implant to beacon through NAT.
VulnCheck registered SPEAKINGSTONE’s forgotten backup domain and watched beacons arrive immediately. As of August 21, 392 unique devices had reported to that sinkhole, including one that had been calling for almost two years. That vivid moment is also a warning about measurement: those devices had no primary server configured and therefore used the backup. The count covers only routers that reached that backup domain.
One packet opens the WAN
DARKLANTERN’s infosrvd service listens on UDP/9992, and the stock firewall explicitly accepts traffic to that port from anywhere. A 19-byte information probe makes the service answer on UDP/8897 with the model, firmware version, MAC address, uptime and other details.
Command packets contain a shell string. The service adds that string to /etc/exec/cmd, and a semicolon escapes the prefix into arbitrary command execution. VulnCheck researcher Jacob Baines summarized the consequence in nine words: “One packet for a root shell over the internet.”
Two checks fail to provide security. The packet checksum uses a hard-coded key, so anyone who recovers the binary can calculate a valid value. The MAC-address gate accepts an all-zero address, even though the information probe already reveals the real MAC. Between August 18 and 21, VulnCheck’s scanner found 203 internet-facing DARKLANTERN instances across 22 countries, self-reporting 16 models.
The 203 systems answered a protocol-specific probe. That confirms a reachable implant service. VulnCheck found no previous public documentation of DARKLANTERN, and the source reports no observed post-exploitation on those routers.
Phone-home control crosses firewalls
SPEAKINGSTONE reverses the direction. Its yunmgrd service sends periodic UDP/10000 registration beacons containing the contents of /tmp/info.txt: model, firmware, MAC address, SSID, LAN address, uptime and, on some devices, location data. Commands return over the same channel in plaintext. The router authenticates neither the server nor the instructions.
On VulnCheck’s WE826-T2, the primary command domain was www[.]ac-link[.]com, resolving during the research to 47[.]107[.]224[.]89. The domain belongs to ZBT and was also present in the earlier ENDLESSDOORS implant. The backup, www.findmyipaddr.com, was unregistered until VulnCheck took control of it as a sinkhole; it is now a defensive analysis surface and should remain undefanged in records.
SPEAKINGSTONE supports these operations:
| Message | Operation | Effect |
|---|---|---|
0x1001 | reg | Send a device fingerprint |
0x2507 | cmdRun | Execute an arbitrary command as root |
0x2502 | pppoe | Return the WAN PPPoE username and password |
0x230b | dnsSet | Write and activate a DNS-hijack list |
0x2306 | dnsGet | Return the current DNS-hijack list |
0x2405 | onoff | Open or close a reverse SSH tunnel |
0x2406 | sshport | Return the reverse SSH port |
0x2602 | setBackup | Change backup command servers |
An attacker needs the configured server position, control of the network path, or an available backup domain to take over SPEAKINGSTONE. That precondition makes it different from the internet-facing DARKLANTERN service. Once the path is controlled, the protocol provides no cryptographic barrier.
White labels hide exposure
ZBT manufactures platforms that other companies resell. VulnCheck connected the WE826 family to Deep Orange in the United States, OneX in Australia, MOFI Network in Canada, and other products or brands in Germany, the Philippines and Russia. The same hardware ancestry does not prove the same firmware ancestry, so procurement records and firmware evidence matter more than a retail logo.
The research published these self-reported DARKLANTERN combinations:
| Vendor | Model | Observed firmware |
|---|---|---|
| ZBT | WE1326 | 18.1218, 19.0717, 19.1101 |
| ZBT | WE2426-C | 19.0412, 19.0626, 19.0829, 19.1101, 19.1112 |
| ZBT | WE357 | 19.1101 |
| ZBT | WE5926 | 18.0904, 19.0617, 19.1101 |
| ZBT | WE5926-EC_QP | 20.0516 |
| ZBT | WE5926-WD | 19.1009, 19.1101 |
| ZBT | WE826-Q | 19.1101 |
| ZBT | WE826-T2 | 19.0226, 19.0617, 19.0809, 19.1101 |
| ZBT | WE826-WD | 19.0426, 19.0625, 19.0809, 19.1023, 19.1101 |
| ZBT | WF3526-P | 19.051 |
| ZBT | WG108 | 19.0809, 19.1101 |
| ZBT | WG3526 | 19.0809, 19.1101 |
| Unknown | CTN720-W1 | 19.0522, 19.1101 |
| Unknown | LF-1541 | 19.1101 |
| Unknown | MT7620N | 19.0412, 19.0809, 19.1101 |
| Unknown | WRC1 | 20.0622 |
The sinkhole observed these SPEAKINGSTONE combinations:
| Vendor | Model | Observed firmware |
|---|---|---|
| ZBT | WE826-T2 | 19.1101 |
| ZBT | L3_V2_8 | 3.0.0.4.528 |
| ZBT | ZBT-7628 | 1.0.0.2.007 |
| ZBT | ZBT-ZBT7621 | 1.0.0.3.001 |
| MoreQuick | MQAC-7620 | 1.0.0.2.000 |
| MoreQuick | MQAC-7620A | 1.0.0.2.000 |
| MoreQuick | MQAP-7620 | 1.0.0.2.000 |
| MoreQuick | MQAP-7620A | 1.0.0.2.000 |
| MoreQuick | MQAP-7628 | 1.0.0.2.000 |
| Unknown | AP522 | 1.0.0.2.014 |
| Unknown | AP7628 | 3.0.0.4.380 |
| Unknown | APG721B | 19.0809 |
| Unknown | HC5661A | 3.0.0.4.380 |
| Unknown | HK300 | 1.0.0.2.032 |
| Unknown | MAP-N10 | 1.0.0.2.044 |
These tables scope an investigation. They do not identify safe firmware versions. VulnCheck did not publish a first-fixed or recommended firmware build. ZBT previously described ENDLESSDOORS as an after-sales support tool used only with customer authorization and said it had never been used for unauthorized access. VulnCheck found no authorization mechanism and argued that the unauthenticated channels prevent the vendor from knowing who has used them.
Figure details
DARKLANTERN runs as infosrvd and accepts inbound UDP traffic on port 9992 because the stock firewall opens that service to the WAN. A crafted command packet reaches the root command helper. SPEAKINGSTONE runs as yunmgrd and sends outbound UDP traffic on port 10000 to a configured command server. An operator controlling that server position or the network path can return unauthenticated instructions for root command execution, PPPoE credential theft, DNS rewriting, or reverse SSH. The two paths converge on root authority but require different exposure and detection checks.
Verify firmware before reconnecting
Start with asset identity. Search inventories, procurement records and device photos for the observed models, white-label variants, the ZBT web marker wk-login-html, the telnet banner 0;0HWelcome to MQWrt@, and the published SSH fingerprints e0ac6c083497d19e5ab3d28f9354e7d84b30793eba720c7f793aeb1ca9be9a41 and ad:9a:52:ad:2b:05:7c:ca:13:7d:12:c6:a7:a9:7e:79. Inspect firmware or process listings for infosrvd, yunmgrd, inetdetect, /etc/exec/cmd, /tmp/info.txt, and /tmp/yunclient.conf.
The binary hashes are 7e2e036fec2fe7ab4bbd43978d9296563894c92a112f5ac2f39957f12108e245 for infosrvd, b77811db4d218c65670a6c9a5b33c30ff81c6d779e15d658643138771178a818 for yunmgrd, and ae6c356f1f09260b859f84d994ef8423540a6c0bdf98510d86b85834283e4926 for inetdetect.
At the network layer, look for inbound UDP/9992, replies from UDP/9992 to UDP/8897, and outbound UDP/10000. Hunt DNS and connection history for www[.]ac-link[.]com and 47[.]107[.]224[.]89. Treat www.findmyipaddr.com as VulnCheck’s sinkhole: a beacon to it is recognition evidence, while the destination itself is no longer attacker controlled. VulnCheck’s published Suricata rules cover the information probe, command traffic, command output, SPEAKINGSTONE registration, root-command messages and credential or DNS operations. Its YARA rules identify the two implant binaries.
Isolate a matching router from untrusted and sensitive networks. Remove UDP/9992 exposure and unexpected UDP/10000 egress as containment while procurement and replacement proceed. Reflashing with an unverified image cannot restore confidence because the implants arrived through firmware and no reliable fixed build is known.
For a controlled verification, run the researcher’s read-only DARKLANTERN identification probe from an authorized test segment. A vulnerable result is a UDP/8897 response beginning with the expected 0c 16 1f bytes and containing model, firmware and MAC fields; the expected clean result is no infosrvd response. Pair a negative network result with firmware hash or YARA inspection, because filtering can silence the service without removing the implant.
The practical boundary is trust in the router image. A device that matches an implant signature should stay isolated until it is replaced or rebuilt from firmware whose provenance and contents can be independently verified. Network silence shows only reachability. It does not prove that root-level code is gone.