threatintel
actor tracker
All briefs

Infrastructure pivot: KV-botnet & Volt Typhoon's residential-proxy plane

Author: Thomas Malinowski Published: 2026-05-18 Status: OSINT synthesis from primary infrastructure reporting Tags: Volt Typhoon, PRC, KV-botnet, JDY-botnet, SOHO routers, passive DNS, JARM, certificate-pivoting, T1090.003, T1584, infrastructure-analysis

Summary

The KV-botnet is a cluster of compromised end-of-life SOHO routers — principally Cisco RV320/RV325 dual-WAN devices, NetGear ProSAFE series, and Axis network cameras — that the PRC state-sponsored group Microsoft tracks as Volt Typhoon (MITRE G1017) operated as a residential-IP relay plane from at least May 2022 through January 2024. Every packet leaving Volt Typhoon's tooling reached the victim through one of these consumer-ISP addresses; from the victim's perspective, the connection originated from a U.S. small business, not from a VPS in a commercial data centre. Lumen Black Lotus Labs first publicly named the botnet in December 2023 and identified a related, larger cluster they labelled JDY-botnet. This brief walks from a single upstream-controller IP through four pivot techniques — passive DNS, TLS/JARM fingerprinting, Censys/Shodan banner analysis, and ASN clustering — to reconstruct how analysts expanded one seed IOC into a defensible infrastructure cluster, ending with the DOJ's January 2024 court-authorized remediation.

Starting point — a single IOC

Pivot seed: 193.36.119[.]48

Sourced from: Lumen Black Lotus Labs KVbotnet_IOCs.txt, February 2024 release.

Characterization in that file: 1st stage Upstream Controller, active timeframe 28 August 2022 – 6 December 2023 — one of the longest-lived nodes in the published set, making it the right starting point for a pivot intended to show cluster breadth rather than just a snapshot of late-2023 activity.

The raw file lists the IP in defanged notation (193.36.119[.]48). All IPs below follow the same convention.

Pivot 1 — Passive DNS

What you ask. Submit 193.36.119[.]48 to a passive DNS service — RiskIQ (now Microsoft Defender Threat Intelligence), Farsight DNSDB, or SecurityTrails — with a query of the form:

# Farsight DNSDB API — rdata lookup
GET /lookup/rdata/ip/193.36.119.48?humantime=true

# SecurityTrails — IP to hostnames
GET /v1/ips/193.36.119.48/hostnames

# RiskIQ PassiveTotal (CLI)
pt host find --ip 193.36.119.48

What you get. The response answers: which FQDNs have ever resolved to this IP, and over what window? From there you invert: which other IPs have those same FQDNs resolved to? The temporal pattern is the analytic signal. Lumen's telemetry showed that KV-botnet proxy nodes had DNS records (when they had them at all) that turned over on a cycle of days to a few weeks — consistent with dynamic or pseudo-dynamic assignments on residential broadband pools — while the upstream controller addresses like 193.36.119[.]48 stayed stable for months. That contrast in TTL behaviour is itself a cluster-membership test: nodes that share a hostname with the seed but turn over on a daily basis are proxy members; nodes that share the hostname and stay stable are likely controller infrastructure.

Lumen's December 2023 and February 2024 writeups are the primary source for the full passive-DNS correlation. The raw telemetry is proprietary to Lumen; what is public is the output — the IOC set in the GitHub repository above. Analysts reproducing this pivot against the published IPs in a commercial passive-DNS platform should expect significant historical coverage for the 2022–2023 window.

Pivot 2 — TLS / JARM / cert fingerprinting

What JARM is

JARM is an active TLS fingerprinting technique, originally published by Salesforce Engineering, that sends ten deliberately malformed TLS Client Hello packets to a target server — varying the TLS version, cipher suite order, and extension set across probes — and records how the server responds to each. The response sequence is hashed into a 62-character fingerprint: the first 30 characters encode which cipher and TLS version the server selected for each probe in reversible form; the final 32 characters are a truncated SHA-256 of the cumulative extensions the server returned. Because the fingerprint captures the behaviour of the TLS stack (the underlying library, its compile-time options, and its configuration), devices running the same embedded OS and the same SSL library version tend to cluster on the same JARM even when their certificates differ. End-of-life Cisco RV32x and NetGear ProSAFE devices running unpatched firmware produce JARM values that are distinguishable from both modern enterprise gear and common VPS-hosted infrastructure.

Querying the fingerprint at internet scale

Censys indexes JARM fingerprints as part of its internet-wide TLS scan. Once an analyst obtains a JARM from a known-bad node (via direct probing or from a vendor's published telemetry), the search is:

# Censys Search — find all hosts with a matching JARM fingerprint
services.jarm.fingerprint:<62-char-hash>

# Combine with port filter to narrow to the proxy plane
services.jarm.fingerprint:<62-char-hash> AND services.port:443

# Further restrict to residential ASNs
services.jarm.fingerprint:<62-char-hash> AND autonomous_system.name:"Frontier"

Lumen's published analysis identified that KV-botnet proxy nodes presented anomalous TLS stack behaviour consistent with the embedded Linux builds in Cisco RV32x firmware — a JARM space that has essentially zero overlap with legitimate cloud-provider infrastructure. Lumen does not publish the specific JARM hash values in their public IOC release; the certificate pivot below is what they chose to surface for external reproduction.

Certificate fingerprinting — what Lumen published

The February 2024 IOC release contains two X.509 certificate SHA-256 fingerprints attributed to KV-botnet infrastructure:

cdffba0ebda39b3b58f59815be3829ca9c1cde957b46a6ad5ce4b31e405455bb
2b640582bbbffe58c4efb8ab5a0412e95130e70a587fd1e194fbcd4b33d432cf

Source: Lumen Black Lotus Labs KVbotnet_IOCs.txt

These are the certificates presented on the proxy or controller nodes' listening services. Certificates that are self-signed with specific organizational fields, or that share a serial number or Subject Alternative Name pattern, can be pivoted across Censys or Shodan using:

# Censys — certificate fingerprint lookup
services.tls.certificates.leaf_data.fingerprint:<sha256>

# Shodan — certificate hash pivot
ssl.cert.fingerprint:<sha256>

Reuse of a certificate across multiple IPs — or reuse of the same Subject or issuer string — directly expands the cluster without requiring any active probing.

Pivot 3 — Censys / Shodan banner pivots

End-of-life SOHO routers expose characteristic service banners even when they have been compromised, because the KV-botnet implant does not suppress the underlying device's management interfaces. Cisco RV320 and RV325 devices expose SNMP on port 161 (and on some firmware builds, port 78) with a sysDescr MIB string that encodes the exact firmware version and build date:

# Observed banner format — Cisco RV320/RV325 SNMP sysDescr
"Linux, Cisco RV320, Version 1.5.1.13 Sat Dec  9 20:04:42 CST 2023"
"Linux, Cisco RV325, Version 1.5.1.05 Tue Oct  1 15:42:08 CST 2019"

Banner strings sourced from live Shodan results for cisco rv320 and cisco rv325. Firmware 1.5.1.x is the end-of-life branch that received no further security updates after Cisco's March 2022 end-of-support date — the same firmware range Lumen and CISA (AA24-038A) identify as the primary KV-botnet substrate.

NetGear ProSAFE devices expose a comparable SNMP sysDescr:

# Observed banner format — NetGear ProSAFE
"GS716Tv3 ProSafe 16-port Gigabit Ethernet Smart Switch, 6.3.1.19, B1.0.04"

KV-botnet nodes additionally opened high-numbered TCP ports (above 50000) on compromised devices to serve as proxy listeners. The combination of the vendor banner, the EOL firmware version, and an anomalous high port is a high-fidelity Shodan / Censys query:

# Shodan — Cisco RV32x EOL firmware with anomalous listener
"Cisco RV320" "Version 1.5" port:443,4443,8443,51235

# Censys — equivalent
services.banner:"Cisco RV" AND services.software.version:"1.5.1" AND services.port:>10000

# Shodan — NetGear ProSAFE with UPnP and high port
"GS716T" "ProSafe" port:51235,3001,8081

The query cuts the global SOHO population to the specific firmware branches and port profiles that Lumen and CISA identified. The resulting IP set is still in the thousands globally, but cross-referencing against passive DNS overlap with the seed IP reduces it to dozens of candidates for manual review.

Pivot 4 — WHOIS / ASN clustering

Once passive DNS, JARM, and banner pivots have produced an IP candidate list, the ASN distribution of that list is itself a signal. Commercial VPS infrastructure clusters on a small number of large ASNs — AWS (AS16509), DigitalOcean (AS14061), Vultr (AS20473), Linode (AS63949) — with consistent WHOIS organization data. The KV-botnet proxy plane did not look like this. Lumen's analysis found the compromised relay nodes distributed across small-to-medium residential and small-business ISPs: regional cable operators, DSL providers, and CLEC networks serving individual U.S. metropolitan areas. The WHOIS organization field on these IPs resolves to the subscriber's ISP, not to any hosting provider. ARIN and RIPE netblock sizes are /24 or smaller, allocated to named ISPs, with SWIP records pointing to residential subscriber pools.

# BGPView / ARIN WHOIS — check ASN for a candidate IP
curl https://api.bgpview.io/ip/174.138.56.21
# Expect: asn.name contains residential ISP, prefix is /24 or smaller

# Bulk ASN distribution check across cluster (Python pseudocode)
import ipwhois
for ip in candidate_list:
    result = ipwhois.IPWhois(ip).lookup_rdap()
    print(ip, result['asn'], result['asn_description'], result['network']['cidr'])

A cluster of hundreds of IPs that spans dozens of different small-ISP ASNs — and where none of the ASNs are commercial VPS providers — is a pattern specific to compromised residential infrastructure. It is not a pattern produced by legitimate corporate VPN exits, Tor exit nodes (which cluster on known ASNs), or CDN infrastructure. That ASN diversity is itself a detection signal distinct from any individual IP reputation.

From cluster to detection

Blocklists are a weak control against a residential-proxy botnet: the IPs churn as infected routers are power-cycled or reassigned, and blocking residential prefixes at scale produces unacceptable collateral damage to legitimate traffic. The cluster constructed above has better uses than a firewall blocklist.

JARM-based alert. Configure network monitoring to flag any inbound connection from a source whose JARM fingerprint matches the KV-botnet node profile — regardless of the source IP's reputation. A Zeek or Suricata rule that logs the server-side JARM of inbound TLS connections can be enriched in a SIEM against a watchlist of known-bad JARM values. This fires on compromised devices even after their IP address changes.

Cert-hash alert. Any connection presenting either of the two Lumen-published X.509 fingerprints is KV-botnet infrastructure. An SSL inspection policy or a passive TLS metadata feed (Zeek ssl.log, Suricata TLS keywords) can match on these hashes without decrypting traffic content.

RDP/SMB from banner-matched residential. Alert on RDP (TCP 3389) or SMB (TCP 445) inbound from any IP whose Censys or Shodan banner identifies it as a Cisco RV32x or NetGear ProSAFE running EOL firmware. Legitimate traffic of this type from consumer routers does not exist.

User-agent and TLS fingerprint mismatch. KV-botnet relayed operator traffic whose TLS client fingerprint (JA3) was inconsistent with a residential Windows host — because the traffic originated from operator tooling, not a browser. Correlating JA3 client fingerprint against claimed residential source is a useful anomaly hunt on proxy-exit traffic.

The takedown

On 31 January 2024, the U.S. Department of Justice announced that the FBI had executed a court-authorized operation to disrupt the KV-botnet. The warrant — obtained in the Eastern District of Texas — authorised FBI agents to issue commands to the compromised routers that caused the KV-botnet malware to delete itself from the device and sever the router's connection to the botnet's command infrastructure. The operation targeted Cisco RV320 and RV325 devices in the United States that had been confirmed members of the KV cluster.

The takedown accomplished: removal of the KV-botnet implant from the targeted U.S. devices; disruption of the botnet's domestic relay capacity at the moment of operation; and the court record establishing that the FBI had technical capability to reverse the compromise on EOL SOHO devices at scale.

The takedown did not accomplish: elimination of the broader threat. Lumen identified the JDY-botnet — a related but distinct cluster, larger in node count and composed of a somewhat different device mix — that remained operational after the KV disruption. The JDY-botnet is assessed to serve a similar relay purpose for Volt Typhoon. Additionally, the court order covered only devices in the United States; the botnet's non-U.S. relay nodes were unaffected. And because the underlying SOHO devices remain unpatched and internet-exposed, new compromises of the same firmware versions resumed after the operation. The KV-botnet name refers to the specific campaign infrastructure disrupted in January 2024; the residential-proxy tradecraft it embodied is an ongoing operational pattern.

Source: DOJ press release, 31 January 2024 — U.S. Government Disrupts Botnet People's Republic of China Used to Conceal Hacking of Critical Infrastructure.

Pivot decision tree

START: You have a single IOC
│
├─ IOC is an IP address
│   ├─ Step 1: Passive DNS (RiskIQ / Farsight / SecurityTrails)
│   │           → What FQDNs resolved here?
│   │           → What other IPs share those FQDNs?
│   │           → Note temporal pattern (days vs. months)
│   │
│   ├─ Step 2: Active JARM probe the IP (if still live)
│   │           → Match hash against known-bad JARM watchlist
│   │           → Query Censys: services.jarm.fingerprint:<hash>
│   │
│   ├─ Step 3: Pull TLS cert fingerprint (Censys / Shodan ssl.cert.fingerprint)
│   │           → Pivot to other IPs presenting same cert
│   │
│   ├─ Step 4: Banner lookup (Shodan / Censys)
│   │           → Does banner identify EOL SOHO firmware?
│   │           → Are anomalous high ports open?
│   │
│   └─ Step 5: ASN / WHOIS
│               → Residential ISP + /24 or smaller? → candidate proxy node
│               → Commercial VPS ASN? → candidate controller node
│
├─ IOC is a domain / FQDN
│   ├─ Step 1: Passive DNS forward resolution history
│   │           → What IPs has this resolved to, over what window?
│   ├─ Step 2: WHOIS registrar, registrant email, nameserver
│   │           → Pivot on registrant email / org to related domains
│   └─ Step 3: Continue as IP pivot above for each resolved IP
│
└─ IOC is a JARM hash
    ├─ Step 1: Censys query → services.jarm.fingerprint:<hash>
    │           → Returns IP set sharing TLS stack behaviour
    ├─ Step 2: For each returned IP → banner + ASN pivot (steps 3–5 above)
    └─ Step 3: Cross-reference IP set against passive DNS for shared domains

References

Primary sources only.