Who Controls Your Router?

A router that phones home with your admin session tokens is just one of fifteen findings in a single firmware image.

Governments and critical infrastructure operators depend on networking equipment whose firmware controls administrative access, external connections, and software updates. Investigating that software across a large network requires specialized expertise, while every firmware update can change the risks.

But, as the below analysis proves in an investigation of a popular industrial router, without that scrutiny, organizations may not know what access their equipment gives to someone outside their network.

This research built on VulnCheck’s findings in ZBT router firmware which drew widespread attention. Using Hero, Dream’s autonomous cyber-defense research bench, the team examined a different model and firmware build: a third-party KWRT image for the ZBT-Z800AX industrial router.

The analysis identified fifteen findings. Five weaknesses undermine software verification, while the firmware automatically restores packages when certain conditions are met and runs daily upgrades. Together, these weaknesses could allow an attacker who compromises the delivery path to install malicious software.

The most concerning finding was a remote-access service configured to start at boot. When the router establishes a WAN connection, the service opens a persistent TLS tunnel to kooldns.cn (an external cloud service using China’s .cn domain) and forwards the owner’s authenticated administrative session tokens to it. If the external service can use those tokens, it could gain access to privileged management functions on the router.

These findings concern one firmware image but they reinforce one overarching result – that organizations carefully scrutinize every aspect of their operation, including popular, off the shelf networking equipment.

What this analysis adds

In August 2026, Jacob Baines at VulnCheck documented ENDLESSDOORS, followed by DARKLANTERN and SPEAKINGSTONE, in ZBT router firmware and traced their spread through the hardware supply chain.

This investigation examines KWRT 25.12-SNAPSHOT r08.25.2026 for the ZBT-Z800AX, a model not named in those reports. It looks at how remote administration, software verification, and automatic installation work together within this build.

The findings apply to this third-party image and its bundled components. They do not establish that ZBT shipped or distributed it, or that it contains the implants described by VulnCheck.

How the remote-access tunnel works

A closed-source, 10 MB Go binary named quickstart runs as a system service and starts automatically at boot. On each WAN connectivity event, it creates a dedicated Linux network namespace and establishes a persistent TLS tunnel to kooldns.cn. It also forwards the device owner’s authenticated administrative session tokens to the cloud side.

Forwarding authenticated administrative session tokens across this tunnel creates a potential route to privileged management functions. The extent of that access depends on the permissions associated with the tokens and the endpoints exposed through the tunnel.

The service starts without requiring the owner to opt in or approve a consent prompt, and its behavior is undocumented.

If the remote service can exercise the forwarded administrative sessions, compromise or misuse of that service could expose connected devices to unauthorized management access. The scope depends on the service’s authentication controls and the population of devices with this functionality active.

DDNSTO and the question of authorization

The same binary includes management functionality for DDNSTO, a remote-access tool that does not require a public IP address. The analysis identified a potential path for activating DDNSTO through the primary management channel.

The security question is whether someone could use that path to enable remote access without the owner’s authorization. The presence of DDNSTO functionality alone does not establish an active second tunnel or continued access after remediation. Those outcomes depend on activation conditions, credentials, and what happens when the services are disabled.

Multiple software-verification controls are disabled

The analysis identified five code paths or configuration choices that weaken package and firmware verification in this image:

• Package signature verification is absent from the base configuration
• A dedicated function actively deletes signature checking if it's ever restored
• The package manager wrapper filters out verification during initialization
• Default processing flags bypass checksum and dependency validation for every operation
• The examined firmware-image verification function unconditionally returns “success,” removing verification at that stage of the update process.

These weaknesses reduce the device’s ability to verify incoming software. The risk grows when the firmware installs packages automatically.

Automatic installation through weakened verification controls

The firmware includes a package-restoration script triggered by network events. It downloads and installs software when specific conditions are met, including the absence of a guard file that prevents repeat execution. The script retries failed attempts and uses Alibaba’s public DNS resolver at 223.5.5.5 as a fallback.

Without effective signature checks, an attacker who replaces a legitimate package with a malicious one could run code with the installation process’s privileges. Compromising the package repository is one route. Replacing a package in transit would also depend on how the download connection is protected and whether it properly validates TLS certificates.

The guard file is stored on the overlay filesystem. If a reset removes it, the restoration process may run again once its other trigger conditions are met.

A separate daily cron job schedules package upgrades, creating an additional automatic installation path affected by the verification weaknesses described above.

Together, automatic restoration and scheduled upgrades create repeated opportunities for software installation. Where an attacker can substitute accepted packages, these mechanisms could turn a delivery path compromise into a device compromise.

The findings and their implications

The fifteen findings span four areas:

These findings can compound. Weak credentials increase the consequences of exposed management services. Missing software verification increases the risk of automatic installation. And remote-access mechanisms may introduce additional paths to administrative functions. The resulting impact depends on which components are active and reachable in the deployed configuration.

Further research could trace these components across other models and firmware builds to establish how widespread the exposure is. Controlled testing could determine what access the forwarded tokens allow and whether fixes survive resets and upgrades.

If the ZBT-Z800AX is on your network

These findings point to three initial checks for security teams assessing this router and its firmware:

• Check whether the quickstart service is configured to start at boot and whether it is running.
• Review outbound DNS and TLS traffic for connections associated with kooldns.cn.
• Verify whether package-signature checking is enabled in the package manager configuration.

These checks help identify behavior relevant to this investigation. They do not establish whether a different firmware build has the same weaknesses.

One firmware image is only the beginning

The questions raised by this investigation apply across an organization’s networking equipment. Organizations must verify which external services can reach management functions, what access they receive, and how the device verifies new software.

In this case, Dream’s research team used Hero, its autonomous research platform, to analyze the image. Given the firmware and a research objective, Hero produced fifteen findings without further human guidance or hints about specific vulnerabilities. The findings show the value of examining remote access, software verification, and automatic installation together.

For governments and critical infrastructure operators, that depth of assessment needs to extend across the device fleet and keep pace with firmware updates. Specialized AI research can help security teams expand that coverage and identify which findings require closer investigation.

Examining deployed firmware and proposed updates gives organizations evidence they can use in procurement, deployment, and remediation decisions. It also gives them a clearer answer to the question behind this investigation: who can control the equipment their networks depend on?

References

[1] Jacob Baines, VulnCheck. "ENDLESSDOORS Is Phoning Home. Pick Up." August 5, 2026. https://www.vulncheck.com/blog/zbt-endlessdoors

[2] Jacob Baines, VulnCheck. "Chinese Implants in the Supply Chain." August 27, 2026. https://www.vulncheck.com/blog/zbt-darklantern-speakingstone

[3] Zak Killian, Tom's Hardware. Coverage of VulnCheck's ZBT router research. August 28, 2026. https://www.tomshardware.com/tech-industry/cyber-security/security-researchers-find-surveillance-implants-in-chinese-made-routers-sold-worldwide-three-different-backdoor-like-implants-hidden-in-firmware