Static Tundra Pulls Your Startup-Config Over Smart Install. The Switch That Leaks It Breaks Its Own Audit Trail

One unauthenticated request to TCP 4786 on an end-of-life Catalyst switch gives an attacker command execution on the box — enough to make it hand over its own startup-config, credentials, SNMP strings, TACACS+ keys and all, through any of several TFTP/FTP paths the operator drives. That is CVE-2018-0171, a Cisco Smart Install remote code execution bug Cisco patched in 2018. Cisco Talos and the FBI both confirmed on August 20, 2025 that Static Tundra, an FSB Center 16 crew operating since at least 2015, is still working it against telecom, higher-ed, and manufacturing networks that never took the gear out of service. The part that should bother anyone running a SOC: the device that leaks the config is the same device you would expect to log the theft — and on the way through, Static Tundra breaks the box’s remote logging so it stops reporting the theft at all.

TL;DR

• Static Tundra (FSB Center 16) is still exploiting CVE-2018-0171, an unauthenticated Cisco Smart Install command-execution bug on TCP 4786, to make end-of-life Catalyst client switches surrender their own startup-config — credentials, SNMP strings, and TACACS+ keys — over TFTP/FTP (including exposing the device’s own TFTP server for retrieval), harvesting configs from thousands of US critical-infrastructure devices in the past year.
• The attack sequence defeats the device-sourced audit trail: the stolen config yields credentials the actors reuse over SNMP/SSH to add privilege-15 accounts and RW community strings, then modify TACACS+ to break remote AAA accounting going forward — so the device you’d check for evidence is the one that just cut off its own audit trail.
• Build detection off the box: NetFlow flags config moving over TFTP/FTP in either direction — the switch pushing outbound, or an external host pulling from the device’s own TFTP server — off-device config diffs (RANCID/Oxidized/NCM) catch the malicious command strings, and a TACACS+ server going silent while the device still forwards traffic is itself the alert.
• Tuning the first week means allowlisting your own NCM/backup server IPs (their nightly config pulls mimic exfiltration), alerting on new RW community strings rather than static ones, and knowing whether you even have inline IDS for the oversized-SMI-packet signatures (Snort SID 46468/46096).
• Config diffing can’t see SYNful Knock, the firmware implant Talos associates with this actor (moderate confidence) that wakes on a magic-packet SYN — so for confirmed-targeted, unpatchable gear the defensible move is replacement, and until then run no vstack, kill SNMPv1/2, isolate from outside the management VLAN, and rotate every credential the config ever held.

Per the FBI’s IC3 advisory, the actors collected configuration files for thousands of networking devices tied to US critical-infrastructure entities in the past year alone. Not zero-days. Not novel tradecraft. A seven-year-old bug in a feature most shops forgot was enabled.

Why Smart Install is still answering the phone

Smart Install was a zero-touch provisioning feature: a new switch boots, phones a director, and pulls an image and config. Useful in 2012. The problem is that on a lot of IOS and IOS XE trains the SMI client sits listening on TCP 4786 whether or not you ever ran the director, and it does not authenticate. Anyone who can reach 4786 can drive it.

Cisco shipped the fix and told everyone to run no vstack. Then the gear aged out. The exposure is specifically a Smart Install client one — Catalyst 2960s, 3560/3750 stacks, 3650/3850s, some 4500 supervisors, and industrial-Ethernet switches, the client platforms that actually sit listening on 4786, some of them forwarding packets in a wiring closet since before the current network team was hired. Not Smart Install directors, and not boxes like the Catalyst 6500/6800, which Cisco lists as not affected by this bug — keep the examples to the client switches. A chunk of that client fleet is end-of-life, unpatched, and still in the traffic path. End-of-life is the whole point of the targeting. There is no fix coming; where a platform or software train can’t support modern encrypted management — SNMPv3, SSH, NETCONF — cleanly, treat that as an end-of-life replacement driver rather than a tuning problem, and nobody wants to touch the box because it is load-bearing. That maps straight to SR (supply chain / component end-of-life) and CM (you are running an unmanaged baseline you cannot patch), and it is exactly the corner of the estate that falls out of the vulnerability-management program because the scanner license stopped covering it.

The exploit itself is one crafted SMI message. The device barely records it locally. So the first instinct — go read the switch’s syslog — is the instinct that fails.

The detection lives off the box, because the box is compromised

Here is the ordering that matters. Static Tundra pulls the config first, which hands over the SNMP community strings and the local credentials. Then it comes back through SNMP or SSH with those credentials and settles in: new privilege-15 accounts, extra read-write community strings, a modified TACACS+ config that quietly breaks remote AAA logging, sometimes a firmware implant. By the time the device is fully owned, its own audit trail is under the attacker’s control. AU on a compromised router is a story the attacker is now writing.

So you build the detection where the attacker does not have a vote. Three places.

NetFlow at the collector. This is where the config theft is visible even when the switch says nothing. You are looking for the switch itself originating a TFTP (UDP 69) or FTP session outbound — the box acting as a client and pushing its own config off to some external host — especially in the window right after a burst of traffic to 4786. But cover both modes: the Talos-documented tftp-server nvram:startup-config chain turns the compromised switch into a TFTP server, and the attacker connects inbound on UDP/69 to retrieve the config, so the suspicious flow may be an external host hitting the device rather than the device reaching out. On a healthy network a management-plane box has no business being either end of a config-sized TFTP/FTP transfer to the outside. Key on flows where a management-plane device address is the source or the destination on port 69 or 21 to/from anything outside the management VLAN — a config push to a Russian VPS range and an inbound pull from the device’s own newly-exposed TFTP server are the same incident from two directions. And it is not always an obvious copy or tftp-server line — Talos also documents SNMP-driven copies via the CISCO-CONFIG-COPY-MIB over TFTP or RCP, so if you still support those older config-copy workflows, watch that path too, not only literal TFTP/FTP commands. In Splunk terms with the Network_Traffic model, a starting pivot:

| tstats count from datamodel=Network_Traffic
  where All_Traffic.dest_port=4786 OR All_Traffic.dest_port=69
  by All_Traffic.src_ip All_Traffic.dest_ip All_Traffic.dest_port

Treat that as a sketch, not a production analytic — it’s one starting pivot that mixes transports and skips device scoping. In practice, split it into separate detections: Smart Install access to 4786 scoped to your device inventory, oversized-SMI packets (below), external TFTP/FTP to or from management-plane devices on 69 and 21, the config-diff detection below, and AAA-silence detection. Combining them in one search buries the signal.

Any hit on 4786 sourced from outside your management segment is worth a page. In most enterprises that port should generate exactly zero flows, ever. If you see a steady trickle, someone’s automation is scanning for it, or you have Smart Install live and did not know.

The config-change stream, collected off-device. RANCID, Oxidized, SolarWinds NCM — whatever pulls running-config on a schedule and diffs it. This is your highest-signal source and it does not depend on the switch narrating anything, because the diff is computed on your server. The Splunk detection guide built around this campaign keys on the command strings that show up in the config after exploitation. The ones worth alerting on:

• tftp-server nvram:startup-config and its running-config variants — staging the config for pull
• snmp-server community <string> rw appearing where you had read-only or nothing
• username ... privilege 15 created outside a change window
• a new interface Loopback with an address that is not in your documented loopback plan
• TACACS+ server or aaa lines changing in a way that drops or redirects accounting

The diff catches these regardless of whether the device logged the change locally, which it often will not, because the same actor is tuning down logging. If you can also ship show archive log config all, you get user attribution on the changes — but treat device-reported attribution as an input, not gospel, since the device is the thing you are investigating.

AAA server logs. Your TACACS+ or RADIUS server sits off the box. When Static Tundra modifies the switch’s TACACS+ config to break remote logging, the absence becomes the signal. A device that authenticated admins through TACACS+ every day and then goes silent — no accounting records, no failed logins, nothing — while NetFlow shows it is still up and forwarding, that gap is the alert. Most teams never build the “device stopped talking to AAA” detection because silence is hard to alert on. Build it. A simple scheduled search that lists management devices with zero TACACS+ accounting events in the last 24 hours, cross-referenced against a device inventory, will surface both a compromise and the far more common case of a switch whose tacacs config rotted after an IP change nobody documented.

What the first week of tuning actually fixes

The config-change detection is noisy out of the gate, and the noise has one dominant source: your own automation. The exact commands that signal exfiltration — copy running-config, tftp-server, config pulls — are what RANCID and Oxidized and NCM do every night by design. If you alert on copy running-config tftp:// with no context, your first morning is a wall of false positives generated by your backup job.

The fix is an allowlist of your config-management server IPs and the accounts they use, applied at the correlation layer, so a config pull to the NCM box is normal and a config pull to anywhere else is the alert. A cleverer regex won’t get you there. Get the NCM server’s source address into a lookup on day one. Everything downstream depends on it.

Second source of noise: SNMP read-write community strings are genuinely common on old gear. Plenty of shops still run snmp-server community public RW because a monitoring tool from 2009 needed it and nobody dared change it. So ...rw in a config is not by itself an incident. What you alert on is a new RW string appearing in a diff, or an RW string being used from a source that is not your NMS. The static presence is a finding for your audit; the change is the detection.

Third: the oversized-packet detection — and it is worth keeping the two mechanisms straight, because they run on different data. Splunk’s oversized-SMI analytic keys on TCP/4786 flows above roughly 500 bytes and escalates severity past ~1000 and ~1400 bytes, because the exploitation payload is abnormally large for what SMI normally carries; that one runs on your NetFlow/traffic model. Separately, Cisco Secure Firewall/Snort coverage ships Smart Install signatures — SIDs 46096 and 46468, with Splunk’s example also correlating 41722–41725 (it fires when two or more trip from one source inside fifteen minutes) — and those need an IDS in front of the management plane. If you have no inline inspection between the access layer and the switch management interfaces — a lot of shops don’t — the Snort signatures never fire and you are back to NetFlow and config diffs. Know which of these you actually have coverage for before you claim the detection exists.

SYNful Knock and the persistence you cannot diff

Config diffing catches the SNMP and account changes. It does not catch a firmware implant. Talos assesses with moderate confidence that Static Tundra is associated with the historical use of SYNful Knock, the modular IOS implant Mandiant first documented back in 2015, which lives in a modified firmware image and wakes on a crafted TCP SYN “magic packet.” A config diff will not see it because the running-config looks clean. This is an SI (software/firmware integrity) problem, and on most of these end-of-life platforms you have no secure-boot attestation to lean on.

Practical checks: verify image hashes against Cisco’s known-good values out-of-band, watch for a device whose behavior does not match its config, and run Talos’s SYNful Knock scanner against the management range. The scanner looks for the implant’s response to the magic-packet handshake. It is a point-in-time check, so it tells you about today and nothing about next Tuesday.

For a box that is end-of-life, unpatchable, and confirmed to be in a nation-state’s targeting set, the defensible move is replacement. Forensic archaeology on the firmware buys you nothing here. If you cannot replace it this quarter, no vstack it, kill SNMPv1/v2, pull it off any interface reachable from outside the management VLAN, and treat every credential and community string that ever lived in its config as burned. Rotate them. The FBI’s own guidance is blunt about this, and I do not disagree: these devices should not be the trusted source of truth for their own configuration.

Control mapping

The uncomfortable summary is that none of this requires the attacker to be clever. It requires you to have a box old enough that it still answers Smart Install, unmonitored enough that config theft leaves no trace you collect, and trusted enough that its own logs are the only thing you would have checked. Take away any one of those and the campaign stalls. The cheapest one to take away is the last: stop trusting the router to tell you what happened to the router.

Sources

• Russian state-sponsored espionage group Static Tundra compromises unpatched end-of-life network devices (Cisco Talos)
• Cisco IOS and IOS XE Software Smart Install Remote Code Execution Vulnerability, CVE-2018-0171 (Cisco Security Advisory cisco-sa-20180328-smi2)
• Smart Install Configuration Guide — Supported Devices (client vs director matrix) (Cisco)
• Russian Government Cyber Actors Targeting Networking Devices, Critical Infrastructure (FBI IC3 PSA 250820)
• CVE-2018-0171 Static Tundra Smart Install detection guide (Splunk)
• SYNful Knock — A Cisco router implant (Mandiant / Google Cloud)
• FBI warns FSB-linked hackers exploiting unpatched Cisco devices for cyber espionage (The Hacker News)
• Russian state cyber group Static Tundra exploiting Cisco devices, FBI warns (The Record)

This post was engineered and validated through a multi-agent AI workflow — drafted, adversarially reviewed by several independent models, checked against primary sources, and given a human review before publishing. See an inaccuracy, or found this useful? Leave a comment below — corrections and feedback are read and shape what comes next.