VulnCheck heeft twee eerder niet gedocumenteerde factory implants aangetroffen in firmware van routers van Shenzhen Zhibotong Electronics (ZBT). Wat dit extra verontrustend maakt: de implant(s) geven een aanvaller die geen account of inlog nodig heeft de mogelijkheid om commando’s uit te voeren met root-rechten op getroffen apparaten. De bevindingen zijn gekoppeld aan de CVE-nummers CVE-2026-74232 en CVE-2026-74233.
In dit artikel lees je wat er precies is gevonden, hoe de implant(s) communiceren, welke routermodellen en firmwarebuilds worden genoemd en welke acties organisaties kunnen nemen om de kans op misbruik te verkleinen.
Wat is er gevonden in de ZBT-firmware?
De onderzoeksorganisatie beschrijft twee implant componenten die in de firmware aanwezig zijn en die elk op een eigen manier toegang tot het systeem kunnen geven.
- SPEAKINGSTONE (CVE-2026-74232): draait als een service met de naam yunmgrd.
- DARKLANTERN (CVE-2026-74233): draait als een service met de naam infosrvd.
VulnCheck heeft beide als CVE’s laten registreren als CNA en rapporteert hoge scores op basis van CVSS. In de beschrijving geldt een scenario waarbij een netwerkaanval kan plaatsvinden zonder privileges en zonder gebruikersinteractie.
Belangrijk detail uit het onderzoek: VulnCheck benadrukt dat SPEAKINGSTONE functioneert als een surveillance-achtige implant met root access op elk apparaat waarop de component draait.
SPEAKINGSTONE: root-commando’s via UDP-beacons en C2
SPEAKINGSTONE communiceert volgens VulnCheck over UDP-poort 10000 richting een hardcoded command-and-control (C2) server. Omdat de implant naar buiten belt (outbound), is de werking volgens de onderzoekers ook mogelijk wanneer apparaten achter NAT zitten en wanneer er normale uitgaande egress-filtering aanwezig is.
Daarnaast noemt VulnCheck meerdere functies in het protocol, waaronder:
- het uitvoeren van willekeurige commando’s als root
- het exfiltreren van gebruikersgegevens van WAN PPPoE (zoals username en password)
- het schrijven en uitlezen van een DNS hijack-lijst
- het openen van een reverse SSH-tunnel
Voor een deel van de blootgelegde signalen heeft VulnCheck ook eigen indicatoren van compromittering (IoC’s) gepubliceerd, waaronder domeinen en paden die verband houden met services en commando-helpers.
DARKLANTERN: een UDP-luisterdienst met zwakke authenticatie
DARKLANTERN (CVE-2026-74233) luistert volgens de advisories op UDP/9992. Het specifieke punt voor netwerkbeheerders: VulnCheck stelt dat de standaard firewall van de routers deze UDP-poort openzet voor inkomende verbindingen vanaf elk internetadres.
Verder geeft VulnCheck aan dat de authenticatie onvoldoende blijkt. In de beschrijving zou de verificatie leunen op een hardcoded salt en een all-zero wildcard MAC-waarde die de eigen adrescheck kan omzeilen.
In de periode tussen 18 augustus en 21 augustus rapporteerde VulnCheck dat er 203 internet-facing DARKLANTERN instances werden gevonden over 22 landen. VulnCheck specificeert daarbij dat het om hosts gaat die op een probe reageerden, niet om met zekerheid gecompromitteerde apparaten.
Welke ZBT-routers en firmwarebuilds worden genoemd?
Een belangrijke nuance in het onderzoek: niet merknaam, maar modelnummer en firmwarebuild zijn volgens VulnCheck het meest betrouwbare criterium. ZBT verkoopt dezelfde hardware en firmware aan resellers die het onder eigen branding kunnen leveren. Daardoor kan “naam op het label” misleidend zijn.
VulnCheck noemt voor de betreffende CVE’s een reeks Zbtlink modellen (en bij sommige records ook andere aangeduide varianten) met specifieke firmwarebuilds. De advisories tonen volgens de brontekst meerdere voorbeelden:
CVE-2026-74233 (DARKLANTERN)
Onder meer worden genoemd (met de bijbehorende firmwarebuilds zoals in de brontekst beschreven): Zbtlink WE1326, WE357, WE5926 en WE826-T2, plus varianten zoals WE826-WD, WG108 en WG3526. Ook andere combinaties met firmwareversies als 19.1101, 19.1112, 20.0516 en 20.0622 komen terug, naast modellen zoals CTN720-W1, LF-1541 en MT7620N.
CVE-2026-74232 (SPEAKINGSTONE)
Voor SPEAKINGSTONE noemt VulnCheck onder meer: Zbtlink L3_V2_8, WE826-T2 en ZBT-7628 met specifieke firmwarebuilds. Daarnaast worden meerdere MQAC/MQAP/MQAP-varianten en AP-modellen vermeld, ieder met hun eigen firmwarevermelding uit het onderzoek.
Een extra complicerende factor voor eigenaren: VulnCheck geeft aan dat advisorypagina’s “upper bounds” tonen, terwijl de CVE-registraties firmware als een exacte build kunnen beschrijven en overige versies standaard op unknown zetten. Dat betekent dat beheerders die buiten de opgesomde builds vallen, geen harde leidraad hebben om te bepalen of de componenten wel of niet aanwezig zijn.
Hoe groot is het risico? Wat het onderzoek opmerkt
VulnCheck koppelt de bevinding aan een supply chain component: de implant(s) zouden als onderdeel van ZBT-firmware zijn geleverd. In de beschrijving wordt ook verwezen naar een eerder door VulnCheck gemelde implant in dezelfde ecosfeer (met een datum en een naam voor een “phone-home” component).
Voor DARKLANTERN beschrijft VulnCheck daarnaast dat het aantal responsen een ondergrens kan zijn, omdat de back-end en query’s niet per definitie alle getroffen apparaten volledig dekken.
Daarnaast benadrukt de brontekst dat VulnCheck bepaalde eerdere componenten adviseerde met defensieve maatregelen op netwerkniveau, zoals het blokkeren/monitoren op egress en resolver en het behandelen van het LAN als niet-vertrouwd.
Praktische aanpak voor beheerders
Als je routers in beheer hebt die mogelijk onder de genoemde ZBT-firmwarebuilds vallen, dan draait de eerste stap om snelle beperking van netwerktoegang en gerichte detectie.
1) Sluit en monitor UDP/9992 aan de rand
Aangezien DARKLANTERN op UDP/9992 luistert en VulnCheck aangeeft dat het om een openstaande listener gaat, kan een blokkade van inkomend verkeer naar die poort op de netwerkedge volgens de guidance helpen om de dienst af te sluiten totdat er een vaste release beschikbaar is.
2) Beperk uitgaand verkeer waar SPEAKINGSTONE naar C2 belt
Voor SPEAKINGSTONE is uitgaand verkeer via UDP/10000 relevant. Omdat de implant naar buiten belt, ligt het voor de hand om uitgaande verbindingen en DNS-/routinggedrag te herzien. Let daarbij specifiek op de door VulnCheck genoemde domeinen en uitgaande paden/karakteristieken die aan de services worden gekoppeld.
3) Zet detectieregels in (Suricata/YARA)
VulnCheck publiceerde volgens de brontekst ook Suricata en YARA regels. Eén van de detecties zou alert slaan op command output die via UDP poorten binnenkomt (met een onderscheid tussen UDP/8897 en UDP/8898 in de beschrijving).
Gebruik deze regels als startpunt voor je eigen monitoring in plaats van ze blind te kopiëren. Stem af op je netwerkarchitectuur, aangezien het om een embedded/protocolmatige service gaat.
4) Ga model- en build-gericht te werk
Omdat merknamen door resellers kunnen verschillen, is het verstandig om inventarisatie te doen op basis van modelnummer en firmwarebuild. VulnCheck geeft aan dat dit de betrouwbaarder methode is om te beoordelen of de betreffende componenten mogelijk aanwezig zijn.
Indicatoren van compromittering (IoC’s) om te verifiëren
VulnCheck publiceert meerdere IoC’s die je kunt gebruiken om te checken op tekenen van aanwezigheid van de services. In de brontekst komen onder andere deze categorieën terug:
- Domeinen: een primair C2-domein voor SPEAKINGSTONE en een backup domein dat door VulnCheck is geregistreerd
- IP-adres: een Alibaba Cloud adres in Shenzhen dat het primaire domein nog zou beantwoorden ten tijde van de controle
- Poorten: UDP/9992 (DARKLANTERN inkomend), UDP/8897/8898 (responses/uitvoer volgens detectieregels) en UDP/10000 (SPEAKINGSTONE beacons)
- Services en paden: onder meer infosrvd, yunmgrd en paden rond een uitvoercmd en tijdelijke bestanden
- SHA-256 hashes: hashes die aan de relevante executables en functies worden gekoppeld
Gebruik deze aanwijzingen vooral om je detectie- en isolatieacties te onderbouwen. Combineer netwerkobservaties met firmware-inventarisatie voor de meest praktische conclusie.
Wat zegt de fabrikant/vermarkter?
In de brontekst staat dat Zbtlink eerder een component (ENDLESSDOORS) heeft behandeld in communicatie: die zou dienen als after-sales technische ondersteuning en alleen op expliciet verzoek en autorisatie. Volgens de aangehaalde woorden is het niet bedoeld voor ongeautoriseerde toegang.
Tegelijkertijd gaat die verduidelijking uitdrukkelijk over de eerdere component en niet over de twee nieuwe implant(s) die in dit onderzoek centraal staan. Er ontbreekt in de brontekst een vergelijkbare publieke bevestiging over de aanwezigheid of afwezigheid van yunmgrd of infosrvd in de huidige firmware.
Daarnaast meldt de brontekst dat de firmwaredownloadpagina’s live waren en afbeeldingen met builds bevatten die relevant zijn voor zowel WE826-T2 als WE2426-C.
Conclusie: behandel de ZBT-routerimplant root als spoedrisico
De kern van deze melding is helder: de ZBT-routerimplant root biedt, volgens VulnCheck, unauthenticated aanvallers de mogelijkheid om commando’s als root uit te voeren op getroffen routers. Met SPEAKINGSTONE voor C2-communicatie en DARKLANTERN als UDP-luisterdienst met zwakke authenticatie ontstaat een scenario waarin compromittering sneller kan plaatsvinden dan organisaties gewend zijn, zeker bij routers die direct internet bereikbaar zijn.
Pak het daarom praktisch aan: inventariseer modellen en firmwarebuilds, beperk inkomende UDP/9992 aan de rand, controleer uitgaande signalen richting C2 voor SPEAKINGSTONE en zet waar mogelijk Suricata/YARA-detecties in. Daarmee verklein je de kans op misbruik én verhoog je je zichtbaarheid, totdat er een solide en verifieerbare firmwareoplossing is.
Wil je meer lezen over gerelateerde router-/internetexposure en snelle mitigaties bij kwetsbaarheden? Bekijk dan ook de CISA KEV update met actief misbruikte kwetsbaarheden voor context over wat er vaak als eerste echt misbruikt wordt.
Bron: https://thehackernews.com/2026/08/china-made-zbt-routers-ship-with-two.html
