KeyDrift: the malware that steals keys in Cisco SD-WAN

There are incidents that go unnoticed because they don't make the front page, but that strike exactly at the fiber on which a company's network hangs. That is what happened with a critical flaw in Cisco Catalyst SD-WAN: according to Cisco Talos, it was exploited to introduce into the systems that govern an organization's SD-WAN network a custom-built malware dubbed KeyDrift. The flaw had been fixed since February, but that did not prevent someone from using it before the update reached all affected equipment.

The part that should most worry any IT manager is what exactly that program does. It does not limit itself to opening a door or leaving remote access: its goal is to copy the keys that encrypt traffic between sites and store them for later use. In other words, the attacker does not just get in, but takes away the master key that protects the company's internal communication.

Why key theft is worse than initial access

When a breach is discussed, the conversation usually focuses on the first access: how they got in, which server was exposed, how long it took to detect it. The KeyDrift case shifts the focus to a later and considerably more uncomfortable phase. If an attacker has the encryption keys for traffic between sites, they can read communications that were supposed to be protected or prepare lateral movement without needing to break anything in real time. The trust placed in the VPN or the encrypted link stops being a shield and becomes an asset in someone else's hands.

In an SME with several offices, a warehouse, or a remote workforce, SD-WAN is often the backbone that connects everything. That is why an incident like this does not stay within the network department: it affects how users authenticate, what data crosses between locations, and the peace of mind with which it can be stated that the information is safe.

The detail that should not be overlooked

Talos describes these attacks as historical, but does not specify when they occurred. That lack of an exact date does not reduce the seriousness of the finding; rather the opposite. It forces organizations to look backward, not only forward. If the patch arrived in February and the malware was planted in the control systems, any company that managed its SD-WAN with unpatched versions during that period should ask itself what passed through its network.

The lesson is similar to the one we already saw with Oracle's flood of patches: having the security bulletin is not the same as having the system protected. Between the publication of the advisory and the effective application of the patch there is a window that attackers know perfectly well and exploit without haste.

What we recommend at ForgeNEX

You do not need to set up an operations center overnight to reduce this risk. What is advisable is to organize a few priorities and treat them as routine, not as an exception:

• Review the Cisco SD-WAN inventory. Identify which versions of Catalyst SD-WAN are in production and confirm that none remains below the February patch. If there is unpatched equipment, that is the first task of the day.
• Rotate the encryption keys between sites. If there is the slightest suspicion that the control environment may have been exposed, changing the keys and reviewing the tunnel certificates is a proportionate and quick measure.
• Monitor the management plane, not only the data plane. The systems that orchestrate the network are a high-value target. Review access, logs, and accounts with privileges over them.
• Check the telemetry from recent months. Although the attack is historical, the logs may still be there. Looking for anomalous connections to the SD-WAN controllers helps confirm or rule out exposure.
• Integrate patch management into the SOC. Tools such as those we discussed in Wazuh and AI to fine-tune a SOC make it possible to detect outdated equipment without expanding staff or budget.

The human factor of the patch

There is a recurring temptation in SMEs: to think that a vendor like Cisco already has everything solved and that the advisory will arrive on its own. The reality is that the advisory does arrive, but the decision to apply it depends on a specific person. If that person is overwhelmed, the window gets longer. That is why it is advisable to assign a clear owner for network updates and set a review cadence, even if it is monthly.

It is also worth reviewing how these solutions are purchased and deployed. Cisco itself has been making moves to streamline purchases in the SMB segment, as we reported in the alliance with Ingram Micro. That ease of acquiring technology should be accompanied by the same ease of keeping it up to date; otherwise, the cost of convenience is paid in the form of an incident.

A sign of where the attack is heading

KeyDrift is not just an anecdote about a specific vendor. It is a sign that attackers are increasingly targeting the infrastructure that guarantees trust: keys, certificates, tunnels. Stealing those pieces allows them to operate calmly and quietly, exactly what a company that needs to know, without doubt, that its sites communicate with each other securely likes least.

The final recommendation is simple to state and somewhat more laborious to execute: treat SD-WAN as what it is, a critical system, and not as just a big router. Patching, rotating keys, and regularly looking at the logs costs less than discovering, months later, that someone was reading the traffic between your offices.

Source: The Hacker News. Analysis and adaptation: ForgeNEX.