The offensive post showed what an attacker does to a Cisco switch or router. This is the other half of the pair: the log lines, flow patterns, and config-change signals that catch each of those techniques while it's happening — so a compromise is an alert, not a surprise you find out about from someone else.
Every technique in Attacking Cisco Gear leaves a trace — you just have to be collecting it and looking. This post pairs each attack with its detection signature: Smart Install and SNMP config-theft show up as unexpected TFTP flows and config-copy syslog; Layer-2 abuse (DTP/VTP) trips port and protocol logs; the post-compromise moves (new users, config changes) are exactly what config-archive and EEM watch for. Detection turns the offensive post's fix list into an alerting list.
The prerequisite is the observability stack — correct time, remote syslog, NetFlow to a collector, SNMPv3. Without those you have nothing to detect with; with them, most of these signatures are a saved search away. Detection doesn't replace hardening — it's the safety net for when hardening is incomplete or a new bug appears.
01
Both unauthenticated config-exfil paths end the same way: the device sends its running-config to an attacker over TFTP. That outbound TFTP flow to a non-management host is the tell.
# NetFlow: the device SENDING UDP/69 (TFTP) to anything that isn't your # provisioning/backup server is the alarm — config is leaving the box. flow: src=<device> dst=<unknown> proto=UDP dstport=69 -> ALERT # Syslog: a config-copy you didn't initiate (SNMP ccCopyTable or SMI): %SYS-5-CONFIG_I: Configured from ... by snmp %SNMP-... copy of running-config to network # Smart Install probes: connections to TCP/4786 from outside management. flow: dst=<device> dstport=4786 src=<not-mgmt> -> ALERT
If you build one detection from this whole post, make it "a network device is the source of a TFTP/FTP/SCP flow to a host that isn't your backup server." Config theft — whether via Smart Install, SNMP-RW, or a logged-in attacker running copy run tftp — nearly always manifests as the device pushing its config outbound. Your switches and routers should almost never initiate file transfers except to known infrastructure; anything else is either a misconfiguration or an exfil, and both are worth a page.
02
Trunk negotiation and VLAN-database changes are loud if you're listening. An access port becoming a trunk, or the VTP config revision jumping, is never normal on a stable network.
# A port unexpectedly negotiating a trunk (DTP / VLAN-hopping attempt): %DTP-5-TRUNKPORTON: Port Gi0/x has become dot1q trunk # on an ACCESS port = alarm # VTP database being rewritten (config revision jump / injected VLANs): %SW_VLAN-4-VTP_...: VTP ... revision N # unexpected jumps = VTP attack # Port-security / BPDU-guard firing (rogue device, MAC flood, rogue switch): %PM-4-ERR_DISABLE: ... err-disabled (psecure-violation / bpduguard)
These are also prevention signals — if you've hardened per Switch Security (access ports nonegotiate, VTP transparent/password, BPDU guard), the attack is blocked and logs the attempt. Alert on the err-disable and DTP-trunk events and you catch the on-LAN attacker in the act.
03
Before the exploit comes the knock: SNMP walks with guessed communities, SSH/Telnet login storms, sweeps of management ports. Rate and failure patterns give them away.
| Recon / brute signal | Where it shows |
|---|---|
| SNMP failures / wrong community | %SNMP-3-AUTHFAIL — repeated = community guessing |
| SSH/Telnet auth failures | AAA/login syslog — a burst from one src = brute force |
| Mgmt-port sweep (22/23/161/4786) | NetFlow: one src touching many mgmt ports/hosts |
| Login from an unexpected source | The login on-success log — geo/host anomaly |
IOS has login on-failure log and login on-success log — enable both and every management authentication, good or bad, hits syslog with source and username. That single pair of commands is the difference between "someone brute-forced us for an hour and we never knew" and a threshold alert on failure bursts. Pair it with an ACL/CoPP so those attempts can only come from management in the first place — then any failure log from outside management is doubly suspicious.
04
An attacker who gets in changes things: a new local user, a modified ACL, an added SNMP community, a config export. The config archive and EEM turn every change into a logged, diff-able event.
# Config-change logging: who changed what, when, from where. R1(config)# archive R1(config-archive)# log config R1(config-archive-log-cfg)# logging enable R1(config-archive-log-cfg)# notify syslog # EEM: page immediately when a config write happens (or when a new # 'username' line appears) — the aftermath alarm. R1(config)# event manager applet CONFIG-WATCH R1(config-applet)# event syslog pattern "CONFIG_I" R1(config-applet)# action 1.0 syslog msg "Config changed — verify" # See the EEM post for reacting on-box; feed CONFIG_I to your SIEM too.
Takeaways
login on-failure/on-success log and SNMP auth-fail — recon and brute force become threshold alerts.A compromised router should trigger a page, not get discovered three weeks later during an unrelated audit. I build detection for Cisco and MikroTik estates — log alerts, flow anomalies, config-change diffing — around exactly that.
Book a Discovery Call →