CVE-2026-74232 & CVE-2026-74233: ZBT Router Factory Implants (SPEAKINGSTONE / DARKLANTERN) — Detection, Hunting, and Remediation Guide

VulnCheck's unpatched vulnerability research team has disclosed two previously undocumented factory implants baked into the firmware of routers manufactured by Shenzhen Zhibotong Electronics (ZBT). The implants — tracked as CVE-2026-74232 (SPEAKINGSTONE) and CVE-2026-74233 (DARKLANTERN) — each independently allow an unauthenticated remote attacker to execute commands as root on affected devices.

Let me be blunt about what this means from an IR chair: these are not memory-corruption bugs requiring exploit development skill. These are deliberate or negligent capability left in shipping firmware. Root-level remote code execution with no credentials on a network edge device is a worst-case primitive — full traffic interception, DNS manipulation, credential harvesting from plaintext protocols, and a persistent pivot point into everything behind the router. Because the implants live in the firmware image, a factory reset does not remove them, and unless ZBT ships a clean firmware rebuild, they persist for the life of the device.

ZBT is a white-box OEM/ODM. Their hardware ships under numerous brand names, which means your exposure assessment cannot stop at a logo check — you need to inventory by hardware origin, not label.

Technical Analysis

Affected Products

• Vendor: Shenzhen Zhibotong Electronics (ZBT), a Chinese OEM/ODM whose router and gateway hardware is widely rebranded and resold by third-party brands, particularly in the SMB, prosumer, and industrial/IoT connectivity segments.
• Affected component: Shipping firmware images containing the SPEAKINGSTONE and DARKLANTERN implants.
• Impact scope: Any ZBT-built device running the implanted firmware, including rebranded units. Specific model enumerations were not published in the initial disclosure — assume exposure until proven otherwise.

CVE Identifiers

Official CVSS scores had not been published at the time of this writing. Based on the described characteristics — remote, unauthenticated, no user interaction, complete device compromise — practitioners should treat both as critical-severity and prioritize accordingly rather than waiting on formal scoring.

How the Implants Work (Defender's View)

A factory implant differs fundamentally from a conventional vulnerability:

1. It is intentional code in the firmware image. It exists on every affected device out of the box, before any attacker touches it. There is no "vulnerable state" to drift into — the capability is always present.
2. No authentication is required. The attack chain is: reach the device's exposed interface → invoke the implant → execute arbitrary commands as uid 0. There is no credential stage to detect, no failed-login telemetry to alert on.
3. Two independent implants (SPEAKINGSTONE and DARKLANTERN) means even if a vendor "fix" removes one mechanism, the second remains a live path. Defenders must validate that both are remediated, not just the one that made headlines.
4. Firmware persistence. Rootkits, config wipes, and reboots do not help. The implant survives because it is the firmware.

Once an attacker has root on the router, the realistic follow-on activity includes: DNS/ gateway redirection for credential phishing and watering holes, TLS-interception-adjacent attacks against plaintext management protocols, lateral movement into flat internal segments, botnet enrollment, and long-term persistence via modified startup scripts or flashed secondary implants.

Exploitation Status

• Disclosed by VulnCheck's unpatched vulnerability research team — "unpatched" is operative here: no vendor fix existed at disclosure.
• The implants were previously undocumented, meaning they have existed in shipped devices for an unknown period with unknown historical exploitation.
• Check CISA KEV and VulnCheck's advisory for current in-the-wild exploitation confirmation. Devices of this class (exposed consumer/SMB edge routers) are historically mass-scanned and botnet-enrolled within days of public disclosure of any unauthenticated RCE primitive. Assume active scanning is underway or imminent.

Detection & Response

The hard truth first: you cannot run EDR on a ZBT router. Detection for this class of threat happens at three places — network telemetry in front of the device, log sources that see HTTP/syslog from the edge, and inventory/hunting from the inside. The detections below target the observable behaviors: unauthenticated command-bearing requests hitting the router's management surface, and post-compromise behavior visible from internal hosts.

Sigma Rules

These two rules target the highest-fidelity observables. The first catches command-injection-style payloads in web requests to embedded/edge devices (ingest from your reverse proxy, WAF, or web server logs where router admin traffic is visible). The second catches shell spawns and command artifacts in syslog forwarded from Linux-based network appliances — many SMB gateways forward syslog, and post-exploitation tooling is noisy.

---
title: Command Injection Patterns in Requests to Network Edge Devices
id: 8c2f4a71-3b6d-4e19-9a52-7f1d5c8e2034
status: experimental
description: Detects shell metacharacters and command-execution strings in HTTP request URIs targeting router/gateway management interfaces, consistent with exploitation of unauthenticated RCE implants such as SPEAKINGSTONE/DARKLANTERN (CVE-2026-74232, CVE-2026-74233).
references:
  - https://thehackernews.com/2026/08/china-made-zbt-routers-ship-with-two.html
  - https://attack.mitre.org/techniques/T1190/
author: Security Arsenal
date: 2026/08/15
tags:
  - attack.initial_access
  - attack.t1190
logsource:
  category: webserver
detection:
  selection_uri:
    cs-uri|contains:
      - ';id'
      - ';cat'
      - ';wget'
      - ';curl'
      - '|id'
      - '`id`'
      - '$('
      - '/bin/sh'
      - '/bin/busybox'
      - 'cmd='
      - 'exec='
      - 'system('
  filter_static:
    cs-uri|endswith:
      - '.css'
      - '.js'
      - '.png'
      - '.ico'
  condition: selection_uri and not filter_static
falsepositives:
  - Vulnerability scanners and authorized penetration tests
  - Embedded device UIs that legitimately pass commands via query strings (rare; investigate before tuning)
level: high
---
title: Shell and Download Cradle Activity in Network Appliance Syslog
id: 2e7b91c4-5f38-4a06-b8d1-6c3a9e5f7128
status: experimental
description: Detects shell invocation and download-cradle commands appearing in syslog forwarded from network appliances and embedded Linux devices, indicating possible post-exploitation activity following router implant abuse (CVE-2026-74232, CVE-2026-74233).
references:
  - https://thehackernews.com/2026/08/china-made-zbt-routers-ship-with-two.html
  - https://attack.mitre.org/techniques/T1059/004/
  - https://attack.mitre.org/techniques/T1105/
author: Security Arsenal
date: 2026/08/15
tags:
  - attack.execution
  - attack.t1059.004
  - attack.command_and_control
  - attack.t1105
logsource:
  product: linux
  service: syslog
detection:
  selection:
    Message|contains:
      - 'wget http'
      - 'curl http'
      - '/bin/sh -c'
      - 'busybox wget'
      - 'chmod +x /tmp/'
      - 'nc -e'
      - 'telnetd'
  condition: selection
falsepositives:
  - Legitimate firmware update processes (typically fetch from vendor domains over HTTPS — validate destination)
  - Administrator CLI sessions on managed devices
level: high

Tuning guidance: Scope the first rule to traffic destined for your gateway/management VLAN IP space if your pipeline supports it — that alone will cut scanner noise substantially. If your routers don't forward syslog, deploy a network sensor (Zeek/Suricata) on the management VLAN and alert on the same payload strings there.

KQL (Microsoft Sentinel / Defender)

This query hunts for command-execution payloads in requests directed at gateway and network-device IP space, using firewall/CEF and syslog ingestion. Adjust the network prefix list to your environment's actual management subnets.

let GatewayIPs = dynamic(["192.168.", "10.0.0.", "10.1.1.", "172.16.0."]);
let CmdPatterns = dynamic(["/bin/sh", "busybox", ";wget", ";curl", ";id", "|id", "$(", "cmd=", "exec=", "system(", "chmod +x"]);
union isfuzzy=true
    (CommonSecurityLog
    | where DeviceProduct has_any ("firewall", "proxy", "waf") or isnotempty(RequestURL)
    | extend Url = coalesce(RequestURL, AdditionalExtensions)
    | where DestinationIP has_any (GatewayIPs)
    | where Url has_any (CmdPatterns)
    | project TimeGenerated, SourceIP, DestinationIP, DestinationPort, Url, DeviceProduct, Activity),
    (Syslog
    | where SyslogMessage has_any (CmdPatterns)
    | where HostIP has_any (GatewayIPs) or Computer has_any ("router", "gateway", "fw")
    | project TimeGenerated, Computer, HostIP, Facility, SeverityLevel, SyslogMessage)
| sort by TimeGenerated desc

Analyst workflow for hits: identify whether the source IP is internal or external. External → the implant is being probed or exploited from the internet; isolate the device and begin IR scoping. Internal → assume the router is already compromised and is being used as a pivot, or an internal host is scanning; check the source host for compromise in parallel.

Velociraptor VQL

Use this hunt across your Windows and Linux endpoints to find hosts with live sessions to router management services (Telnet, SSH, HTTP/S on gateway addresses) — unexpected admin-plane connections from workstations are a strong post-compromise lateral-movement signal.

-- Hunt for endpoint connections to router management services on gateway addresses
SELECT Pid, Name, Path, Family, Type, Status,
       Laddr.IP AS LocalIP, Laddr.Port AS LocalPort,
       Raddr.IP AS RemoteIP, Raddr.Port AS RemotePort
FROM netstat()
WHERE Status =~ 'ESTAB'
  AND RemotePort in (22, 23, 80, 443, 8080, 8443)
  AND (RemoteIP =~ '^(192\\.168\\.|10\\.|172\\.(1[6-9]|2[0-9]|3[01])\\.)')
  AND NOT Name =~ '(?i)(chrome|firefox|msedge|teams|outlook)'

Pair this with a pslist() sweep for interactive shell clients toward embedded devices:

-- Find telnet/nc/ssh client usage that could indicate router interaction
SELECT Pid, Name, CommandLine, Exe, Username, CreateTime
FROM pslist()
WHERE Name =~ '(?i)(telnet|nc|ncat|putty|plink)'
   OR CommandLine =~ '(?i)(busybox|/bin/sh|telnet )'

Remediation & Verification Script

No patch existed at disclosure, so the job is find → isolate → verify exposure → replace. This Bash script discovers candidate ZBT/embedded devices on your network, enumerates their exposed management surface, and flags anything that responds unauthenticated. Run it from a management host with network reachability to your edge segments.

#!/bin/bash
# ZBT Implant Exposure Assessment - CVE-2026-74232 / CVE-2026-74233
# Run from a management host. Requires: nmap, curl, arp-scan (optional)
set -euo pipefail

TARGET_NET="${1:-192.168.1.0/24}"   # Override with: ./zbt_assess.sh 10.0.0.0/24
OUT="zbt_assessment_$(date +%Y%m%d_%H%M%S)"
mkdir -p "$OUT"

echo "[*] Discovering live hosts on $TARGET_NET"
nmap -sn "$TARGET_NET" -oG "$OUT/live_hosts.gnmap" >/dev/null
awk '/Up$/{print $2}' "$OUT/live_hosts.gnmap" > "$OUT/targets.txt"
echo "[+] $(wc -l < "$OUT/targets.txt") hosts discovered"

echo "[*] Enumerating management surface (web, telnet, ssh, upnp)"
nmap -iL "$OUT/targets.txt" -p 22,23,53,80,443,1900,7547,8080,8443 \
     --open -sV -oN "$OUT/services.txt" >/dev/null
echo "[+] Service results in $OUT/services.txt"

echo "[*] Checking MAC OUIs against known Shenzhen Zhibotong / ZBT prefixes"
# Look up vendor OUI from ARP scan output; add prefixes confirmed in your environment
arp-scan --localnet --interface eth0 2>/dev/null | grep -iE 'zhibotong|zbt|shenzhen' \
  | tee "$OUT/zbt_oui_hits.txt" || echo "[!] No ZBT OUI matches (rebranded units will not match by OUI alone)"

echo "[*] Banner-grabbing web interfaces for ZBT/GoAhead/Boa fingerprints"
while read -r host; do
  for port in 80 8080 8443; do
    resp=$(curl -sk --max-time 5 "http://$host:$port/" 2>/dev/null || true)
    if echo "$resp" | grep -qiE 'zbt|zhibotong|goahead|boa/|we[bs]erver'; then
      echo "$host:$port -> $(echo "$resp" | grep -oiE '(zbt[a-z0-9-]*|goahead[^<]*|boa/[0-9.]+)' | head -1)" \
        | tee -a "$OUT/suspect_devices.txt"
    fi
  done
done < "$OUT/targets.txt"

echo ""
echo "=== ACTION CHECKLIST ==="
echo "1. Cross-reference $OUT/suspect_devices.txt and service banners with asset inventory"
echo "2. Confirm hardware OEM (FCC ID / board markings), not just the brand label"
echo "3. Remove ANY suspect device from internet-facing exposure immediately"
echo "4. Block inbound management ports at the perimeter: 22,23,80,443,7547,8080,8443"
echo "5. Isolate suspect devices into a quarantine VLAN pending replacement"
echo "6. Review DNS/gateway configs on all downstream hosts for tampering"

Firewall-side immediate mitigation (apply at your perimeter now, regardless of inventory status):

# Block unsolicited inbound to embedded management services from the internet
# Example: iptables on a Linux perimeter gateway
for port in 22 23 80 443 7547 8080 8443; do
  iptables -A INPUT -i wan0 -p tcp --dport $port -m conntrack --ctstate NEW -j DROP
done
# Egress: alert on LAN devices initiating outbound to known scanner/botnet infrastructure
# via your existing threat-intel feed integration

Remediation

There is no vendor patch at the time of this writing — this is an unpatched disclosure. Work the problem in this order:

1. Inventory by hardware origin, not brand. ZBT is an OEM/ODM. Pull asset records, FCC IDs, MAC OUIs, and firmware banner strings. Contact your resellers directly and demand written confirmation of the board OEM for any router/gateway product they've sold you.
2. Remove internet exposure today. No management interface on any edge device should be reachable from the internet — that was true before this disclosure and is non-negotiable after it. Disable remote administration, disable UPnP, and block inbound management ports at the perimeter.
3. Segment. Move suspect devices into a dedicated VLAN with no lateral path to server or workstation segments and egress filtering to only required destinations. A compromised router on a flat network is a domain compromise waiting to happen.
4. Rotate everything that transited the device. If a device was internet-exposed, assume interception: rotate DNS-resolver configurations, any credentials sent over plaintext protocols, and wireless PSKs. Check downstream hosts for DNS/gateway tampering.
5. Plan replacement, not patching. A factory implant is a supply-chain trust failure. Even if ZBT ships updated firmware claiming remediation of CVE-2026-74232 and CVE-2026-74233, independent verification that both implants are removed — and that nothing else shipped in their place — is required before redeployment. For most organizations, the correct answer is procuring replacement hardware from a vendor with a published security response process.
6. Monitor vendor and CVE record updates. Watch the CVE records for CVE-2026-74232 and CVE-2026-74233, VulnCheck's advisory, and CISA KEV for exploitation confirmation and any future mitigation guidance. If a CISA KEV entry lands, federal deadlines apply and your own remediation SLA should tighten accordingly.
7. Procurement control. Add firmware-provenance and coordinated-disclosure requirements to your hardware procurement checklist. This is the second-order fix that keeps you out of the next one of these.

Related Resources

Security Arsenal Managed SOC Services AlertMonitor Platform Book a SOC Assessment soc-mdr Intel Hub