How a Fake Branch Office Took Over the Network: Inside UAT-8616’s SD‑WAN Hack

SD‑WAN in Plain Terms: Why This Hack Matters

In the video, Ed Woodruff from Low Level TV walks through what he calls the most advanced hack he’s covered: a real‑world compromise of Cisco SD‑WAN systems by the threat actor UAT‑8616, also known as Salt Typhoon.

To set the stage, he first explains SD‑WAN at a high level:

• Old model: Companies with many branches historically relied on private leased lines (T1/T3) and later MPLS (Multi‑Protocol Label Switching) to connect branch A to branch B over private, unencrypted networks.
• SD‑WAN upgrade: Software‑Defined Wide Area Networks let branches communicate over any transport (internet, private links, etc.) while centrally defining how traffic is routed. It’s more flexible and can use encryption and policy‑based routing.

Because SD‑WAN frequently sits at the edge of critical infrastructure—like water and power utilities—the security of its controllers and management planes is crucial. That’s exactly what UAT‑8616 targeted.

Who Is UAT‑8616 / Salt Typhoon?

Ed bases the story on public reporting from Cisco Talos about a Chinese threat actor:

• UAT‑8616, also called Salt Typhoon, has been observed exploiting zero‑day vulnerabilities in edge and network devices.
• Their targets include critical infrastructure sectors in the US and worldwide, especially operational technology (OT) environments like:
  • Water utilities
  • Power companies
  • Other industrial and infrastructure networks

In this campaign, they abused weaknesses in Cisco Catalyst SD‑WAN systems to gain deep, persistent access to enterprise networks.

Step 1: Faking a Branch via SD‑WAN Peering

SD‑WAN controllers manage many branches. When a new branch joins, it has to peer with the controller and prove it belongs to the organization. Typically this uses:

• Public/private key exchanges, or
• Pre‑shared symmetric keys

The idea: a new branch says, “I’m part of the company; here’s proof,” and the controller accepts it into the management/control plane.

According to the Cisco Talos reporting Ed cites:

• UAT‑8616 exploited a vulnerability in the SD‑WAN peering mechanism.
• Details are not public—there is no proof‑of‑concept, and the exact cryptographic or protocol bug isn’t known.

What is known from the Talos write‑up, as described in the video:

• The attackers were able to create a fake branch in the SD‑WAN fabric.
• This fake node appeared like any other legitimate branch on the network map.
• From there, they could:
  • Advertise IP routes
  • Inject and receive network traffic
  • Join the management/control plane with limited privileges

So the first win for the attackers was quietly becoming just another branch—with enough access to reach the controllers, but not yet root.

Step 2: Firmware Downgrade to Revive an Old CVE

Once inside the SD‑WAN network as a low‑privilege participant, UAT‑8616 moved to privilege escalation. Ed highlights a particularly clever part: they executed a firmware downgrade attack.

Why downgrade?

• Software is (in theory) more secure over time as vulnerabilities are found and patched.
• Older firmware often still contains known, documented bugs—like CVEs from prior years.

In this case, Ed points to:

• CVE‑2022‑20755 – a vulnerability in the CLI (command‑line interface) of Cisco SD‑WAN software.
  • Only accessible to an authenticated local user.
  • Allows escalation to root.

From the story as he tells it:

1. The attackers, acting as a fake branch, gained low‑privilege management plane access.
2. They downgraded targeted SD‑WAN systems (vCenters / controllers) to a firmware version that still contained CVE‑2022‑20755.
3. With that older image running, they could trigger the old bug to escalate to root.

Ed notes this is a textbook reason many vendors try to block firmware downgrades:

• If an attacker already has some access, the ability to roll back to vulnerable code effectively hands them an older, weaker security baseline to exploit.

Step 3: Path Traversal and Vshell Abuse to Reach Root

To explain the escalation path, Ed dives into an example of a classic path traversal vulnerability, then connects it to how the Cisco bug worked.

What is a path traversal?

He sketches a simplified scenario:

• A web tool takes a user‑supplied path and serves a file from /var/www/uploads/<user_path>.
• If the code doesn’t sanitize the input, the user can supply ../../../../etc/passwd instead of a harmless filename.
• The system then opens /etc/passwd, a sensitive file, even though that was never intended.

This is the essence of a path traversal: using sequences like ../ to walk up the directory tree and access files outside the allowed area.

How this mapped to the Cisco SD‑WAN exploit

According to the vulnerability description Ed summarizes:

• The vulnerable component was Vshell, the SD‑WAN CLI environment.
• When a user logs in, Vshell generates a config file using a filesystem path plus the username.
• If the username isn’t sanitized, an attacker can embed traversal strings in it.

The attack chain he describes from the research:

1. Crafted username

   • The attacker sets a username like .temp/../foo/../external (placeholder example) that includes traversal sequences.
   • This tricks Vshell into reading a file located outside the intended directory.

2. Leak a sensitive IPC secret

   • Using this technique, the attacker reads confd_ipc_secret (a secret used for inter‑process communication between components on the system).
   • With that secret, they can sign IPC requests as if they were a trusted process.

3. Run Vshell as root

   • The exploit script shown in the write‑up (as Ed recounts) uses the leaked secret to request that a command run as UID 0 / GID 0 (root).
   • Example flow:
     • Run: python temp/exploit.py 123 to leak confd_ipc_secret.
     • Then use that secret to invoke Vshell or other commands as root.

So the escalation sequence is:

• Fake branch → low‑privilege CLI access → path traversal in Vshell → leak IPC secret → signed IPC calls as root → full system compromise.

Detection, Mitigation, and Why This Is So Dangerous

Ed closes with practical takeaways for anyone operating similar environments, based on Cisco Talos guidance.

What defenders should look for

He mentions several indicators and patterns:

• Suspicious SD‑WAN peers

  • Check logs for new control connections and peers.
  • Especially flag peers:
    • Coming from public IP addresses that aren’t in your expected list
    • With geolocation or ownership that doesn’t match your organization

• Signs of privilege escalation via traversal usernames

  • Look for login attempts or CLI sessions involving crafted usernames containing traversal sequences like ../.
  • These can hint at attempts to trigger the Vshell path traversal / configuration bug.

• Standard persistence artifacts (general good practice)

  • Unrecognized SSH keys in authorized_keys
  • Suspicious entries in known_hosts
  • Changes to sshd_config or other security‑sensitive configs

Mitigation steps

Within the bounds of what he describes:

• Upgrade firmware on affected Cisco SD‑WAN systems to patched versions that fix:
  • The peering/authentication bypass vulnerability, and
  • CVE‑2022‑20755 and related privilege escalation issues.
• Review whether your devices allow firmware downgrades and how that’s controlled.
• Improve monitoring of control‑plane events and peering relationships.

Ed stresses that if you manage one of these networks, the baseline action is straightforward: update your firmware and comb through logs for anomalous peers or crafted usernames.

Would Rust Have Saved the Day?

Ed addresses a common question in his audience: could this attack have been prevented if the software was written in Rust instead of C/C++?

He’s cautious and keeps the answer tied to what’s publicly known:

• The peering/authentication bug:

  • If it’s a cryptographic design or implementation error (e.g., hard‑coded keys, missing signatures, bad hash usage, logic errors in a state machine), Rust would not inherently fix that.
  • Rust addresses memory safety, not flawed crypto designs or logic.

• The Vshell path traversal / IPC abuse:

  • If any part hinges on memory corruption during parsing, Rust could help.
  • But if the core problem is input validation and path handling logic, that’s still up to the programmer, even in Rust.

He also notes a practical constraint:

• Many carrier‑grade routers and SD‑WAN systems run on real‑time operating systems (RTOS) with tight performance and scheduling requirements.
• Real‑time Rust is still a developing area. Projects like Embassy and Arctic exist, but it’s not yet a universally solved or mature space for all vendors.

So in this example, Rust isn’t a silver bullet; the problems appear to be design and logic rather than purely memory safety.

Final Summary

In this Low Level TV episode, Ed Woodruff unpacks a sophisticated real‑world attack against Cisco SD‑WAN systems by the threat actor UAT‑8616 (Salt Typhoon). The campaign combined:

• A peering/authentication flaw that let the attackers create a fake branch in a company’s SD‑WAN fabric.
• A firmware downgrade to resurrect CVE‑2022‑20755, a known CLI privilege‑escalation bug.
• A path traversal in Vshell to leak an IPC secret and ultimately execute commands as root.

The result: a low‑privilege foothold as a bogus branch was turned into full control of SD‑WAN controllers, with potential impact across every branch of a target organization.

Ed’s key takeaways are to keep SD‑WAN firmware updated, monitor for unexpected peers and crafted usernames, and recognize that while safer languages like Rust help with memory safety, they don’t automatically solve cryptographic or logic‑level design flaws. The attack chain he describes shows how layered weaknesses—peering, downgrade capability, and CLI bugs—can combine into one of the most advanced practical hacks seen against wide‑area network infrastructure.