Most people treat the router like plumbing: install it once, forget it, hope it behaves. That’s the exact mindset Russia’s FSB Center 16 counts on. A new joint advisory from the NSA, FBI, CISA, and international partners says this group is actively hunting internet-exposed routers that still run with weak/default SNMP community strings, then using spoofed IPs to pull device configuration files and exfiltrate them using TFTP. If your router sits at the edge of anything important, this is a “check it today” situation—not a “someday” project.
What’s happening: the router is the target, not the side quest
The latest joint warning from US and allied agencies isn’t about some exotic zero-day. It’s about a boring, very fixable pattern: internet-exposed routers that still answer to weak/default SNMP community strings, then quietly cough up the keys to the kingdom.
Here’s the attack chain in plain English, using the same flow defenders are seeing in the wild:
- SNMP scans on the public internet
The FSB Center 16-linked group scans IP ranges looking for routers that respond to SNMP with default/common “password-like” strings.
- Weak/default SNMP community string accepted
If your device still accepts something easy (or never-changed defaults), they can query and control parts of device management over SNMPv2c-style access.
- Spoofed IP requests to blend in
They issue commands using spoofed IP addresses. That matters because it can make logs look like the request came from “inside” or from a trusted management range—exactly the kind of detail that slows triage down.
- Router configuration file copied
The goal isn’t to “own” one router for fun. The goal is to copy the device configuration.
- TFTP exfiltration (UDP/69) to actor servers
They exfiltrate via TFTP to servers they control. It’s low-friction and still enabled in places it shouldn’t be.
Why router config files are a goldmine
A router config is basically a network blueprint plus access hints. Even when passwords are hashed, configs can still expose enough to plan follow-on access:
- VPN details (endpoints, crypto settings, sometimes pre-shared-key handling)
- ACLs and firewall rules (what’s allowed, what’s blocked, what’s trusted)
- Internal IP ranges and routing (how to move laterally once they get a foothold)
- Management surfaces (SNMP settings, admin interfaces, allowed source IPs)
That’s why this is bigger than “network gear hygiene.” The advisory calls out targeting tied to energy, communications, defense industrial base, healthcare, financial services, and government—but don’t let that lull you. If you’re an MSP, a vendor with VPN access into customers, a regional healthcare clinic, or a mid-sized manufacturer, your edge router can still be the easiest way into something an attacker actually cares about.
If you’re wondering “would we even notice?”, that’s the uncomfortable part: the router is treated like plumbing, so it often has the least monitoring—while sitting at the most important choke point.
The weak spots they’re betting you still have
This kind of router breach doesn’t win because attackers are brilliant. It wins because a few small “we’ll fix it later” decisions pile up, and the edge device ends up exposed in exactly the ways a scanner can find in minutes. The joint advisory is blunt about what they’re hunting for: default/common SNMP authentication strings, plus paths to pull data off the device.
1) SNMPv2c community strings that never got changed
SNMPv2c still shows up in real networks because it’s easy. The catch: it’s built around a shared secret called a community string.
If that string is still something common (or inherited from the last admin), you’ve basically got a management password that:
- gets reused across devices,
- gets pasted into scripts and NMS tools,
- sticks around for years because “nothing broke.”
Attackers don’t need to guess your entire security posture. They just need one router that still accepts a default/common string.
2) SNMP and TFTP reachable from the internet (even “just temporarily”)
A lot of exposure is accidental:
- A temporary firewall exception to “let monitoring work” that never got removed.
- A WAN rule copied from an old template.
- A vendor support change that opened things up for troubleshooting and stayed that way.
When SNMP is reachable from the public internet, it’s discoverable at scale. When TFTP (UDP/69) is reachable, it’s a simple path for moving files around—exactly what these campaigns abuse for config theft.
3) “Helpful” legacy features that quietly become a front door
Legacy features are dangerous because they feel internal and “safe” until they’re not.
The advisory notes this actor has also gone after Cisco’s Smart Install (SMI), tied to CVE-2018-0171, and has been linked to targeting critical infrastructure through that weakness since at least November 2021.
This is the classic inherited-network problem:
- The router nobody wants to touch because downtime is scary.
- The end-of-life box that became “permanent” after one budget cycle too many.
- The feature that was enabled for a past rollout and never revisited.
If any of that sounds familiar, you’re not behind. You’re normal. You just can’t stay normal on the internet-facing edge anymore.
Practical mitigation checklist (do this in order)
If you’re going to fix this, fix it like you’d fix a gas leak: fast, in order, and with proof. The joint advisory’s mitigation guidance is pretty direct: upgrade to SNMPv3, disable Cisco Smart Install, block SNMP/TFTP at the edge firewall, update software/firmware, and replace end-of-life devices .
1) Stop the easiest remote management wins
- Move from SNMPv2c to SNMPv3
Use SNMPv3 with authentication and encryption (often called authPriv). The point is simple: no more “community string” that behaves like a shared password.
- Kill default access paths
- Change any default/shared management creds.
- Remove old read-write SNMP users unless you truly need them.
2) Remove the “file-copy lane” attackers count on
- Block SNMP at the edge firewall (don’t just “hide it”)
If monitoring needs it, pin it to a known management source IP range over VPN or an internal network.
- Block TFTP at the edge firewall
If you still use TFTP internally for legacy workflows, keep it internal-only and document why it exists.
3) Close legacy doors you didn’t mean to leave open
- Disable Cisco Smart Install / address CVE-2018-0171 exposure
If it’s on, treat it like an internet-facing admin service. Turn it off or restrict it hard.
4) Patch what you can; replace what you can’t
- Update router firmware / network OS
Put network gear in the same patch cadence as servers. If updates are “too risky,” that’s usually a sign you need better maintenance windows and rollback plans.
- Replace end-of-life (EOL) devices
EOL is where “we can’t patch” turns into “we can’t defend.”
5) Verification, not vibes (what to confirm after changes)
Check these like a checklist, not a feeling:
- No WAN-exposed SNMP (external scan should show closed/filtered)
- No WAN-exposed TFTP (UDP/69)
- Config backups exist and are stored securely (restricted access, audited)
- Alerts for config changes are turned on (or at least syslog events forwarded)
If you want one quick gut-check: if your router can be managed from the open internet “for convenience,” you’re betting your network on nobody noticing. Attackers notice.
Router campaigns are stacking up: a quick reality check
If this feels like a one-off “router thing,” it’s not. What’s changed is how attackers value the box at the edge: routers are getting treated like high-value infrastructure, because they sit in the perfect spot to redirect traffic, harvest credentials, and map networks quietly.
A clean example is FrostArmada. Authorities disrupted it after it infected 18,000 routers across 120 countries by December 2025 . The play wasn’t complicated: compromise SOHO/SMB routers (including MikroTik and TP-Link), change DNS settings, then redirect authentication traffic to attacker-controlled servers to steal Microsoft 365 logins and OAuth tokens . The FBI-led operation even remotely removed the malicious DNS settings and pushed devices back to legitimate resolvers .
Different campaign, same lesson: once someone controls your router settings, they can shape what users see and where “trusted” logins actually go.
If you suspect exposure, treat it like your config is already in someone else’s hands
Don’t wait for perfect evidence. Act like a grown-up about it.
Immediate actions (same day)
- Rotate secrets that could live in or be implied by router configs
- VPN credentials / pre-shared keys
- Admin credentials used for device management
- Audit the router configuration
- Look for unexpected management users, new ACL entries, new port forwards
- Check DNS settings on the router
- WAN DNS servers, DHCP-offered DNS, and any hard-coded resolvers
Network-level checks (same week)
- Review logs/flows for outbound TFTP traffic to unfamiliar hosts and unusual SNMP activity patterns (especially from/to the internet).
- Pull configs from devices you care about and compare against a known-good baseline. If you don’t have a baseline, that’s your first gap.
If you’re in a spot where rotating credentials across routers, VPNs, and cloud apps is messy (it usually is), this is where tools like Cloaked can help reduce blast radius for people-facing exposure by limiting what real identifiers get handed out in the first place. It won’t harden your router, but it can keep a router compromise from turning into a clean line to your team’s inboxes and accounts.
