Volt Typhoon at Year Three: Pre-Positioning Detection in 2026

Three years on from the first public Volt Typhoon disclosures, the campaign hasn’t gone anywhere. The naming has fragmented — Volt, Vanguard Panda, BRONZE SILHOUETTE, KV-botnet operators, whatever the next vendor decides to call them — but the underlying tradecraft has barely shifted. Compromise an end-of-life edge device, use it as a relay, ride harvested credentials into a flat enterprise network adjacent to OT, and live there quietly on built-in Windows tooling until something useful happens. The 2024 CISA advisory called it pre-positioning. In 2026 the more honest word is resident: in several US water and electric distribution networks the access has outlived the staff who would have had any reason to look for it.

This post is about the defender problem, not the geopolitics. The geopolitics you already understand: Taiwan timeline, retaliation options, the value of being able to brown out a regional substation without firing a missile. What I want to do here is walk through what the detection actually looks like at a SOC console, where the first-week false positives come from, and which environment assumptions completely change the answer.

The shape of the intrusion

The edge-device foothold is the part most teams cannot fix directly, and it’s the part vendors keep underselling. The KV-botnet work that Lumen and the FBI took down in early 2024 was running on Cisco RV320/325s, NETGEAR ProSAFEs, Axis cameras, and a smattering of DrayTek units — all EOL, all sitting on commodity ISP allocations, all owned by small businesses who have no idea they are part of a relay network for cross-Pacific operations. The takedown helped. It did not end the technique. My read is that by mid-2025 the same operators had moved to a different mix of SOHO gear (some Fortinet 40F/60F units that never got patched for the 2024 SSL-VPN bugs, plus a refreshed crop of Ivanti Connect Secure boxes), and the relay infrastructure regenerated within a quarter.

What lands inside your enterprise from one of those relays is usually not malware. That’s the part to internalize. It’s an interactive session over a stolen VPN credential, or an SMB authentication using a hash pulled from an internet-facing appliance’s config dump, or a Citrix logon from an IP that geolocates to a residential cable modem in Ohio. The malicious work is then done with cmd.exe, wmic, ntdsutil, vssadmin, netsh, reg.exe, nltest, and PowerShell — the same tools your sysadmins use, which is the entire point.

What to actually hunt

Forget IOC feeds for this one. Hashes don’t help when the binary is C:\Windows\System32\ntdsutil.exe. Anchor on behavior and on the combinations of commands that have essentially no legitimate explanation outside DC maintenance.

The single highest-value signal is still ntdsutil.exe invoked with ifm or create full arguments. In a Splunk environment with Sysmon and 4688 turned on, the search is roughly:

index=win EventCode=4688 (New_Process_Name="*\\ntdsutil.exe" OR Process_Command_Line="*ntdsutil*")
| search Process_Command_Line="*ifm*" OR Process_Command_Line="*create full*" OR Process_Command_Line="*ac in ntds*"

In a 5,000-endpoint environment with a couple of dozen DCs, expect this to fire approximately never on a normal day. If you see it on a member server or workstation, that’s the call. If you see it on a DC, page the DC admin and confirm a maintenance window — and if they say no, you’re past the point where this post is useful and into IR.

vssadmin create shadow is messier. Backup software uses it. Veeam uses it. Some monitoring agents touch it. The discriminator is what runs after it: a shadow copy creation followed within seconds by a copy or robocopy against \HarddiskVolumeShadowCopy*\Windows\NTDS\ntds.dit is not something a backup product does, because backup products use VSS writers, not raw file copies out of the shadow namespace. Build the detection as a sequence, not a single event. Splunk transaction or stats with earliest()/latest() over a 60-second window works; the Elastic equivalent through EQL is cleaner but the field mapping is uglier because process.command_line gets truncated at 2048 bytes in the default Winlogbeat config and the shadow path is long enough to clip. Yes, that’s still the default. No, they haven’t fixed it as of the 8.15 release; could have changed since.

netsh interface portproxy add v4tov4 is the one I’d most expect a tired SOC to miss. It’s how the operators turn a beachhead host into an internal pivot for SMB or RDP without dropping a binary. The command is rare in clean environments but not unheard of — some legacy jumpbox patterns use it, and at least one VPN client (Pulse, back when it was still called that) used to lay one down during install. Detection is straightforward; tuning is the work. Allowlist by host role, not by command line, because the command line is exactly what the operator will mimic.

WMI event subscription persistence — Sysmon Event IDs 19, 20, 21 — is the persistence mechanism I’d bet on seeing if any persistence is dropped at all. SCCM/MECM clients produce a steady background hum of these. The discriminator is the __EventConsumer class: legitimate management uses CommandLineEventConsumer or ActiveScriptEventConsumer pointed at signed binaries or well-known script paths, and the operators historically use CommandLineEventConsumer with a base64-encoded PowerShell command in the CommandLineTemplate field. Search for base64 patterns in CommandLineTemplate or for command lines exceeding ~200 characters in WMI consumers and you will pull most of it. You will also pull SCCM’s compliance scripts on the first day, which is the tuning work.

The telemetry reality

This is where most of the writeups stop being useful. A 4688-with-command-line policy at enterprise scale is not free. On a Windows 10/11 fleet running Office and a typical browser load, you’re looking at 50k–200k process creation events per host per day, dominated by browser child processes and Office telemetry helpers. Ten thousand seats is comfortably north of a terabyte a day of just 4688 before you’ve parsed anything. Splunk-licensed shops feel that immediately. Cribl in front of the indexer helps if you’re willing to drop or sample on a curated allowlist of high-volume noise (chrome.exe child processes, OneDrive sync helpers, MsMpEng scan invocations), but every field you drop in transit is a field your detection can’t pivot on later. Pick what you keep with the hunt queries in mind, not the storage bill.

The other piece nobody warns you about: time skew. Sequence-based detections (vssadmin then copy within 60 seconds) fall apart when your member servers are 8 seconds ahead of your DCs because the PDC emulator’s external NTP source got firewalled off in a CM change six months ago and nobody noticed. Check your w32tm /query /status output before you trust any temporal correlation. If your skew is north of ~2 seconds across the fleet, widen your detection windows and accept the false positive rate that comes with that.

EDR coverage gaps are the third one. Volt Typhoon-aligned activity has shown a clear preference for hosts that sit in awkward management seams — the jumpbox between IT and OT, the legacy 2012 R2 box still running because of one vendor application, the Citrix VDA pool that the EDR team carved out of policy because it was breaking session logons. Those are the hosts where the tradecraft works. If your asset inventory says 100% EDR coverage and your reality is 94% with the 6% concentrated exactly where pre-positioning would land, your detection program has a hole the size of the actual problem.

What the first week of tuning looks like

The shape is consistent. Day one you turn on the ntdsutil and vssadmin-sequence rules, and the ntdsutil rule is silent and the vssadmin rule generates a flood from your backup infrastructure. Carve out the backup service accounts by SID, not by process parent — the operators can spoof parent processes and the SID list is auditable. Day two the WMI subscription rule lights up with MECM compliance baselines; allowlist by the specific consumer name pattern your CM team uses, and only that pattern. Day three the netsh portproxy rule flags one or two real legacy jumpboxes and a forgotten install script from an MSP that left three years ago. Document the jumpboxes; kill the install script’s residue. By the end of week one you should be down to a handful of alerts a day across the suite, and the ones left should be high-fidelity enough to page on.

The rule most teams get wrong on the first pass is the ntdsutil detection — not because it’s hard to write, but because they scope it to DCs and miss the operator running it from a member server with stolen DC credentials over a remote session. Scope it everywhere. The DC-only scoping is intuitive and exactly backward.

Where this maps in 800-53

If you’re an ISSO writing this up for a continuous monitoring narrative, the relevant family hits are unsurprising: SI-4 for the detection content itself, AU-6 and AU-12 for the audit pipeline that has to actually carry 4688 with command-line data, CM-7 for the least-functionality argument that should have killed ntdsutil execution on non-DCs years ago (it didn’t, because nobody enforces application control on member servers), AC-17 for the remote access surface the campaign rides in on, IA-2 for the credential reuse that makes the pivot work, and SC-7 for boundary protection at the edge appliances themselves. SR-3 and SR-11 are the awkward ones, because the supply-chain story for SOHO and edge gear is that you do not control it and the vendor’s EOL date arrives faster than your refresh budget. CA-7 is where the program-level honesty lives: continuous monitoring against this adversary is not a quarterly scan, it’s the rule tuning loop above, run weekly, forever.

The uncomfortable part

The detections work. The tuning is doable. The reason this campaign keeps succeeding is not that the tradecraft is exotic — it isn’t, it’s 2017-era red team material with better operational discipline — but that the seam between IT and OT in a regional water utility or a co-op electric distributor is staffed by three people, one of whom is on call this week, and the SIEM is a managed service whose detection content was last reviewed by a vendor SOC analyst who has never seen a SCADA historian. The technical answer is in this post. The organizational answer is the one CISA keeps writing JCDC advisories about and the sector keeps not funding. Until that changes, the resident-access problem stays resident.