Lumen says Volt Typhoon ran four confirmed zero day campaigns through disposable relay chains and prints no indicators

Two minutes to build, 4.1 hours to use, and no indicators printed

Lumen's Black Lotus Labs says a Volt Typhoon "Silent Train" chain can be assembled in under two minutes, and its Figure 3 puts the median session at 4.1 hours. On those two figures, building a chain costs about 0.8 per cent of a median session (derived: 2 minutes over 246). The report, published on 28 October 2026, says the Labs has tracked Silent Train for three years, notified hundreds of victims, and that its monitoring helped uncover "at least four confirmed and one likely" zero day vulnerabilities. Counted by this site from the full text, it prints no IP address, no domain name and no file hash.

What that does not establish. The report does not say how many of the hundreds of notified organisations were breached rather than targeted, it names no victim, and it gives no count of chains, sessions or compromised devices. It states the attribution to Volt Typhoon as fact without a stated confidence level, except for one campaign. And a Black Lotus Labs researcher told CyberScoop that the observations "should not be interpreted as a complete census of Volt Typhoon activity". Read the numbers below as what one vendor's telemetry saw.

This briefing follows Lumen's own post, read in full from about 18:41 UTC on 28 October 2026, the day its page data gives as the publication date. BleepingComputer and CyberScoop were read for what they add, and the CVE records and CISA's catalogue were read directly. Cisco's advisory page redirected to a sign in and Arista's advisory page answered a client challenge, so neither was read and nothing here relies on them.

Lumen sells network security. Its page points readers to its Lumen Defender product and describes the Labs' mission as to "leverage our network visibility to help protect customers". A report that shows what the vendor's own telemetry can see is also a showcase for that telemetry. That is not a reason to doubt the observations. It is a reason to read the attribution and the scale as the vendor's account.

What Silent Train is, and what it is not

Lumen describes Silent Train as a framework built around "rapidly rotating chains of compromised SOHO, IoT and enterprise devices", exploited on demand, used against carefully selected targets, cleaned up after each operation and continuously refreshed. It says that distinguishes it from traditional botnets, proxy networks and operational relay box (ORB) networks. It is a way of building and discarding a path, not a standing network. The researcher who spoke to CyberScoop said chains are assembled and dismantled every day, so the number of nodes at any one moment is "effectively close to zero", and that this makes it "fundamentally difficult to disrupt because there isn't one network to take down".

Zoom

Zoom

The timing matters as much as the topology. Lumen says operators could assemble chains "in under two minutes", and that sessions "averaged about four hours, though some lasted only minutes". Each session typically involved one to five victims, often a single organisation. Activity ran Monday to Friday, mostly between 09:00 and 22:00 China Standard Time, which is 01:00 to 14:00 UTC (derived, from the UTC+8 label on Lumen's Figure 7), with multiweek reductions around Chinese New Year. Lumen reads that as people at work rather than automation, and as matching military rotational schedules. The second reading is inference.

Zoom

Lumen adds a point that cuts against the four confirmed zero days being the whole story: "Some relay device types lack known vulnerabilities, suggesting Volt Typhoon leveraged undisclosed zero-day exploits to set up a single relay". That is the vendor's inference about the relay side. It is not part of the count of four.

Five management platforms, four confirmed zero days, and what the public record says

Lumen's Figure 9 lists five campaigns against management and control plane platforms. Four it calls confirmed zero days and one, Quest KACE, a likely one. The table sets Lumen's windows beside what CVE.org and CISA's catalogue record for the same flaws. Lumen's caption says: "Time ranges indicate when vulnerabilities were assessed as zero-days, not the full exploitation duration by Volt Typhoon."

Zoom

Zoom

Three readings, each derived from the table. First, the longest confirmed window, N-central at 12 months, is four times the Versa window of 3 months. Second, the four confirmed windows add to 20 campaign months (3 + 12 + 3 + 2, overlapping in August 2024), and each window ends at or near the CVE's publication, so a patch applied on the day of the vendor's notice came after all of those months. Third, disclosure did not end the exposure: CISA gave due dates of 2 to 21 days, and Lumen says Cisco exploitation continued well after February 2026. The report does not say how Lumen confirmed each zero day, only that notifications led to incident response investigations that uncovered them. Of the other devices it names, it says its telemetry "could not always determine whether access involved known or undisclosed vulnerabilities". This site covered the VeloCloud flaw and a later one in an earlier briefing.

Stated and not stated: the record, line by line

"Not stated" means not found in Lumen's post, read in full, or in the two news reports. It does not mean Lumen does not know.

Attribution deserves a separate line. In the report, only the KACE campaign carries a stated confidence, "moderate-confidence assessment that Volt Typhoon exploited a zero-day vulnerability". Lumen's 2024 post on the Versa flaw attributed that exploitation "with moderate confidence to the Chinese state-sponsored threat actors known as Volt Typhoon and Bronze Silhouette". The 2026 report states no such hedge for Versa and says Volt Typhoon throughout. The working hours are circumstantial: a weekday day shift in UTC+8 shows where operators work or where they want to look as if they work, and the report does not say which. The joint advisory AA26-113A, released on 23 April 2026 by the UK's National Cyber Security Centre with 15 named partner bodies (derived count), names Volt Typhoon among the Chinese state sponsored actors that use covert networks of compromised devices. As read, it does not mention Silent Train. It also warns of what it calls "indicator of compromise (IOC) Extinction": a threat group can now come from one of many covert networks, so static lists of malicious addresses work less well.

Labels that stand in for a control

Five labels in this story sound like a control or a boundary. None is one.

Method is separate from accusation. A vendor describing what its telemetry saw is a legitimate method, and the report is specific about the architecture, the timing and the products. The accusation, that this was Volt Typhoon and was aimed at strategic access, rests on circumstantial patterns and the vendor's judgement, and the report says the reason for the geographic focus is unclear. Lumen also has a commercial reason to be believed, as set out at the start.

Technical details

The Lumen report prints no indicators of compromise, no detection rule and no command. The artifacts below are what the primary sources do print: the port labels on two of Lumen's example chains, the tools and techniques it names, the hunting advice as written, the affected and fixed versions from the CVE records, the CISA catalogue entries, and the detection steps in Lumen's 2024 post on the Versa flaw. Each block is attributed to its source and the day it was read. Nothing here is an exploit or a working indicator list, and no address is given.

The first two blocks are this site's transcription of the labels drawn on Lumen's Figures 5 and 6. They are examples of single sessions, not a fixed profile. Several ports in the examples are high numbers, such as 8236, 8103 and 14737, and the two figures do not share them, so a rule keyed to one port is a weak control (this site's inference). A defender can use them to ask which management and edge devices answer SSH or HTTPS on unexpected ports, and from where. The asterisks on two device labels in Figure 5 are not explained in the text read. The alt text on Lumen's page places two of the Figure 5 labels on a different hop from the drawn figure; the blocks follow the drawn figure.

Volt Typhoon > UCloud
UCloud > Alibaba Cloud : SSH/22, SSH/8236
Alibaba Cloud > TP-LINK WR* : HTTPS/443, SSH/2222
TP-LINK WR* > Alibaba Cloud : HTTP/8281 (return arrow)
TP-LINK WR* > Netgear Orbi* : HTTPS/8443, SSH/2222
Netgear Orbi* > Fortigate : HTTPS/10443
Fortigate > Victim
Bracket Non-U.S. : Volt Typhoon to TP-LINK WR*
Bracket U.S. : Netgear Orbi* to Victim

Volt Typhoon > UCloud
UCloud > Huawei Cloud : SSH/22, SSH/8103
Ruckus vSZ > Huawei Cloud : Chisel, TCP/8999 (arrow points back toward the cloud server)
Ruckus vSZ > Cambium cnPilot : HTTPS/8443, SSH/14737
Cambium cnPilot > Victim
Bracket Non-U.S. : Volt Typhoon to Ruckus vSZ
Bracket U.S. : Cambium cnPilot to Victim

The report describes what the operators left on a relay for the length of a session, and what they took away. This is the sentence as printed, followed by the line on reverse tunnels.

its operators exploit exposed web interfaces on SOHO, IoT and other relay devices, then deploy only the tooling needed to enable chained SSH access through the compromised node. This included temporary SSH services, keys, configuration files and "live off the land" utilities. At the end of each session, operators removed all artifacts and dismantled the chain.

some operations mixed in reverse tunnels via open-source proxies like Chisel and FRP, sending traffic from compromised devices to upstream infrastructure.

What Lumen says it found on the management platforms after exploitation, and its hunting advice. A defender can turn each line into a search of the platform's own audit log, API log and file transfer history.

Post-incident analysis with partners uncovered in-memory webshells, credential harvesting and abuse of native features such as endpoint control and remote file transfers. In several cases, the actors also erased or altered logs and other evidence of exploitation and operator activity.

Monitor and investigate unusual administrative logins, network or endpoint administration activity, abnormal API usage, remote file transfers and configuration changes.
Hunt for suspicious "live off the land" activity that falls outside normal administrative timeframes or workflow patterns.
Centralize logging, extend retention and export security telemetry wherever possible.

The version strings below are from the CVE records as published by the CNA named in each, read on 28 October 2026. Cisco's and Arista's own advisory pages could not be read, so no fixed Cisco version is given here. The VeloCloud record's solution text names three release trains while its affected list has a fourth, 7.0.0 before 7.0.0.1; the record does not settle what that means for the 7.0 train.

CVE-2025-8875  N-able N-central. Assigner N-able. Published 2025-08-14.
  Deserialization of Untrusted Data vulnerability in N-able N-central allows Local Execution of Code.
  This issue affects N-central: before 2025.3.1.
CVE-2025-8876  N-able N-central. Assigner N-able. Published 2025-08-14.
  Improper Input Validation vulnerability in N-able N-central allows OS Command Injection.
  This issue affects N-central: before 2025.3.1.
CVE-2026-16812  Arista Networks, VeloCloud Orchestrator On-Prem. Assigner Arista. Published 2026-07-27. CWE-78.
  Affected: 5.2.0 before 5.2.3.14; 6.1.0 before 6.1.3.4; 6.4.0 before 6.4.2.4; 7.0.0 before 7.0.0.1
  Fixed in the following releases: VCO 5.2.3.14 and later in the 5.2 train; VCO 6.1.3.4 and later in the 6.1 train; VCO 6.4.2.4 and later in the 6.4 train
  Workaround bullets (three of four):
    Restrict access to the VCO web interface to trusted administrative networks.
    Monitor for unexpected outbound network activity from the VCO host.
    Review recent administrator activity for unexpected changes.
CVE-2026-20127  Cisco. Assigner cisco. Published 2026-02-25. CVSS 3.1 base score 10.0.
  A vulnerability in the peering authentication in Cisco Catalyst SD-WAN Controller, formerly SD-WAN vSmart, Cisco Catalyst SD-WAN Manager, formerly SD-WAN vManage, and Cisco Catalyst SD-WAN Validator, formerly SD-WAN vBond, could allow an unauthenticated, remote attacker to bypass authentication and obtain administrative privileges on an affected system.
CVE-2024-39717  Versa Director. Assigner hackerone. Published 2024-08-22. CVSS 3.0 base score 6.6.
  The "Change Favicon" (Favorite Icon) option can be mis-used to upload a malicious file ending with .png extension to masquerade as image file.

CISA's Known Exploited Vulnerabilities feed, version dated 27 October 2026, holds an entry for each of the five CVE ids. The dates are CISA's.

CVE-2026-16812 | Arista VeloCloud Orchestrator | dateAdded 2026-07-27 | dueDate 2026-07-30
CVE-2026-20127 | Cisco Catalyst SD-WAN Controller and Manager | dateAdded 2026-02-25 | dueDate 2026-02-27
CVE-2025-8876 | N-able N-Central | dateAdded 2025-08-13 | dueDate 2025-08-20
CVE-2025-8875 | N-able N-Central | dateAdded 2025-08-13 | dueDate 2025-08-20
CVE-2024-39717 | Versa Director | dateAdded 2024-08-23 | dueDate 2024-09-13

Lumen published detection steps for the Versa flaw in August 2024. They are the only concrete detections in the sources read, and they are for one product. The first is a network pattern, the others are file and port checks.

We assess the short timeframe of TCP traffic to port 4566 immediately followed by moderate-to-large sessions of HTTPS traffic over port 443 from a non-Versa node IP address (e.g. SOHO device) as a likely signature of successful exploitation.
Blocking external/northbound access to ports 4566 and 4570, ensuring these ports are only open between the active and standby Versa Director nodes for HA-pairing traffic.
Searching the Versa webroot directory (recursively) for files ending with a ".png" extension that are not valid PNG files.
Expedited patching of Versa Director systems to version 22.1.4 (or later), or apply a hotfix as described in Versa's security advisory sent to customers on August 8, 2024.

From the joint advisory AA26-113A (23 April 2026), the baselining advice for any organisation that is a target of covert networks, copied as printed.

Map and understand network edge devices, developing a clear understanding of organizational assets and what should be connecting to them.
Baseline normal connections, especially to corporate virtual private networks (VPNs) or other similar services.
Would you expect connections from consumer broadband ranges?
Implement multifactor authentication for remote connections.

Not printed in any source read: file hashes, domains, IP addresses, YARA, Sigma or Suricata rules, the KACE vulnerability details, and any list of the devices Lumen says were compromised.

What to do, in the order worth doing it

Every step is advice Lumen or the joint advisory already gives, or follows directly from the CVE records. None needs an indicator list, which is the point: the report gives none.

Zoom

For the wider pattern of covert networks and the Chinese companies the advisory says build them, see this site's earlier briefing on the Integrity Tech seizure affidavit, which concerns the company the advisory names as having controlled and managed the Raptor Train network.

Key facts