SURIQ
Start with the part the coverage buried: you cannot patch this, and you may not know you own one. VulnCheck disclosed a remote-access implant baked into the firmware of 20 router models sold under the Zbtlink name and its white-label siblings, and the vendor has no fixed firmware to ship. The affected-model list is real, but it is the wrong place a defender starts, because the same hardware ships rebranded under several labels. The signal you can actually trust is the router calling out to a stranger every 35 seconds.
VulnCheck CTO Jacob Baines found the implant after a test router on his desk kept trying to reach servers he had never configured. His team named it ENDLESSDOORS. It is built on rctl, a small remote-control-for-Linux project last touched in 2015, and it rides in 21 firmware images across 20 models. Zbtlink stated the capability was meant only for after-sales maintenance and debugging on sample units, then pulled the affected firmware from its download page and acknowledged unspecified firmware security issues. Baines' team reads it as a deliberate implant rather than a later compromise.
What the implant actually does
Two processes pose as the Linux kernel worker thread kworker, run with root privileges, and come up at boot from an init script called skworker. One of them calls out to hardcoded command servers as often as every 35 seconds, per VulnCheck. Its check-in carries little more than a padded label and the device's own LAN MAC address, with no key exchange and nothing on the wire to prove who is on the other end. Replies from the server drop straight into popen() as root, unfiltered and unsandboxed, and one trigger string opens a live interactive shell on port 7001. Control the four servers and you hold every one of these routers at the same moment.
Four endpoints steer the fleet, spread across Alibaba Cloud, Vultr, and a Jiangsu host so no single takedown clears them:
zbtctl.epplink[.]netat 47.100.190[.]96- 47.107.224[.]89, hardcoded with no name attached
online-string[.]comat 45.32.81[.]152rbdg4nzqadui.wikaba[.]comat 43.248.136[.]125
That traffic rides port 7000. One more detail worth sitting with: VulnCheck chose not to warn the vendor first. Telling Zbtlink about a capability Zbtlink built, they reasoned, would mostly alert whoever operates the servers.
Why the model list is the wrong starting point
The affected units are white-label boards from one Shenzhen manufacturer, resold under Zbtlink, Wiflyer, ZBT, and ZBTWiFi labels. So the sticker on the case and the model in your asset inventory may not line up with VulnCheck's list, and a defender who only greps a spreadsheet of SKUs will miss the rebranded ones. The reliable tell is behavioral, not nominal: an edge device reaching a fixed set of foreign IPs on port 7000 on a tight, machine-regular interval is doing something no home or small-office router should do on its own. Hunt the call-out, then confirm the model. Not the other way around.
That check-in is also cleaner to catch than most command traffic because it is dumb and periodic. Human-driven malware jitters its callbacks to blend in. A maintenance implant on a fixed 35-second timer does not. A single rule on your gateway segment that flags any internal device holding a steady outbound rhythm to a small set of external hosts on an odd high port will surface this and a dozen unrelated problems worth knowing about.
The fake-kworker heuristic, and why it travels
The masquerade the implant uses is a gift, because it breaks a rule that real kernel threads never break. A genuine kworker is a kernel thread. It has no file on disk, it never holds a network socket, and its parent is kthreadd at PID 2. The implant is a userland program wearing that name. So a process claiming to be kworker that owns a TCP connection, or that maps back to an on-disk binary, is by definition an impostor. That check is worth adding to your hunt library well beyond this vendor, because naming a payload after a kernel thread is a tired trick plenty of other implants reuse.
| Signal | Real kworker | ENDLESSDOORS impostor |
|---|---|---|
| Backing file on disk | None (kernel thread) | Yes, at /usr/sbin/kworker |
| Holds a network socket | Never | Yes, outbound TCP 7000 |
| Parent process | kthreadd (PID 2) | Userland init chain |
| Config file | None | /etc/kworker.cfg |
On a device you can reach a shell on, the on-disk indicators are direct: the fake binary at /usr/sbin/kworker, the loader /usr/lib/librctl.so, the config at /etc/kworker.cfg, and the boot script /etc/init.d/skworker. On a device you cannot log into, which is most consumer routers, the network call-out is your only vantage point, which is exactly why the egress rule matters more than the file list.
No patch is coming, so treat the router as untrusted hardware
There is no fixed firmware, and even if Zbtlink ships one, the honest question is whether you would trust an update channel that already delivered a standing root shell across two dozen models and years of releases. A root-level implant with no vendor fix cannot be cleaned in place. The sound response is to isolate the device, replace it, and treat everything that transited it as observed: any credential, session, or management traffic that crossed one of these routers should be considered exposed and rotated. Blocking egress to the four endpoints above is a stopgap, not a cure, because the operator can move infrastructure faster than you can chase it.
If any of this feels familiar, it should. We have watched a forgotten router turn into a scanning node, a legacy Cisco flaw get exploited with no patch on the way, and a run of backdoors dressed up as ordinary tooling. The recurring lesson is not about one brand. The edge device nobody configured, the one humming quietly in a closet, is often the one carrying the standing shell. The gear at the boundary deserves the same egress monitoring and the same suspicion you already give your servers, because the boundary is where the quiet command channel lives.