Cybersecurity briefing
/
The Router Still Works After the Attacker Changes It
Attackers can change a router's settings while it keeps forwarding traffic. Learn why reviewed baselines, config history and independent logs matter.
/
AUTHOR
Jeff Dyer
/
SHARE THIS ARTICLE
Overview
A router can keep the business connected while quietly serving an intruder. In its October 29 incident-response report, Cisco Talos described espionage operators creating privileged accounts, disabling logging and altering network configurations to maintain access. For organizations accustomed to treating an outage as the signal that infrastructure needs attention, these intrusions expose a different failure: the network continues working after its security settings stop reflecting the organization's intent.
The report concerns observed telecommunications intrusions, not evidence that every enterprise faces the same campaign. Its lesson applies wherever routers, switches and security appliances hold settings that determine who can administer the network and where traffic can travel.
Legitimate features can carry unauthorized instructions
Talos reports that attackers used valid credentials and a known web-management vulnerability, CVE-2023-20198, to gain access. They then used ordinary infrastructure functions, including VPN access, traffic mirroring and management protocols, for malicious purposes. This is current reporting about an established vulnerability and observed operations, rather than a newly disclosed flaw.
The distinction matters because a software update and a configuration review answer different questions. An update can address a vulnerable code path. It does not, by itself, establish that every privileged account or traffic-handling rule remaining on the device belongs there.
Traffic mirroring illustrates the problem. Engineers use it to send copies of traffic to monitoring equipment. An unexpected destination deserves investigation even when the command is valid and the router reports no fault. The security question concerns the purpose and authorization of the setting, not whether the operating system accepts it.
That makes configuration state part of the incident evidence. Security teams need to know what changed, when it appeared and whether an authorized person approved it. A ticket saying that maintenance succeeded cannot supply those answers on its own.
The newest backup may preserve the wrong state
An automatically collected configuration is a record of what the device reported at a particular time. Calling that record the approved baseline requires another decision.
Suppose a hypothetical branch router acquires a second administrator account during an intrusion. A nightly backup faithfully captures the account. If the newest backup automatically becomes the recovery standard, the organization risks restoring the unauthorized access along with the legitimate settings.
Retain configuration history and distinguish collected state from reviewed state. A difference should lead to a comparison with approved work and, where available, independent authentication and administrative records. Missing records should remain an investigation gap rather than being interpreted as evidence that nothing happened.
The joint communications-infrastructure hardening guidance issued in December 2024 makes the trust boundary explicit: maintain configurations centrally and investigate changes outside the approved process, instead of allowing the device to define its own trusted configuration. Although written for communications infrastructure, the agencies identify relevance to enterprise equipment as well.
A baseline also needs maintenance. Approved routing changes and replacement equipment can make an old configuration unsuitable. Review must preserve legitimate operational changes while separating them from unexplained additions. Simply restoring the oldest available file can create an outage without resolving the compromise.
Make comparisons routine and corrections deliberate
Maintaining that discipline across several manufacturers is difficult when each device requires a separate login and a different comparison procedure. Network configuration-management platforms give teams a consistent way to collect settings, compare versions and apply defined checks across supported infrastructure.
BackBox's Kilter platform compares device configurations, checks them against configured requirements and supports corrective automation or a ticket for investigation. Its backup and recovery functions retain configuration history and validate backups at creation and before restoration. Those functions connect a detected difference with a repeatable operational response.
Backup validation still does not establish that the saved configuration is free of attacker changes. Nor does a configuration comparison identify every implant or prove that a valid account was used legitimately. Engineers must establish the approved state, choose which discrepancies can be corrected automatically and validate the exact device family, version and intended operation before deployment.
For an unexpected administrator account, the immediate response may be to preserve evidence and investigate. An automatic rollback could erase useful context or interrupt the team managing the incident. Routine drift and suspected compromise should therefore have different response paths, even when the same comparison mechanism discovers them.
Keep evidence outside the device under review
Configuration history becomes more useful when it can be checked against records the suspected device cannot rewrite. The joint guidance recommends centralized logging and copies stored away from the equipment. Protect the management system and its credentials as carefully as the devices it controls.
Forwarding logs requires an operational check, too. Confirm that records actually arrive at the collector and that a stopped stream becomes visible to someone responsible for investigating it. A logging destination in the configuration is only one part of that evidence path.
Before relying on recovery automation, run a controlled exercise on representative non-production equipment. Introduce an approved test deviation, check whether it is detected, and follow the investigation or correction path. Then verify both the intended security setting and continued application connectivity. Record exceptions that prevent the workflow from working as designed.
Leadership can ask for a concrete result: how much of the critical network has a reviewed baseline, usable history and a demonstrated recovery path? Unchecked devices and unexplained changes should remain visible. A network that forwards packets successfully has passed an availability test. Establishing that it still operates under the organization's rules requires evidence about its configuration.
