Attack path analysis case study: from guest Wi-Fi to the core banking database
Security reports usually list weaknesses one at a time, each with its own severity rating. Attackers do not work that way. They combine small weaknesses into a route to what they want, and this client’s board needed to see those routes.
Why would six medium findings worry a board?
The client was a conglomerate with three very different businesses. It had corporate IT, manufacturing plants run by operational technology (OT, the systems that control physical equipment), and a banking subsidiary. All three shared one identity and access management platform, the system that decides who can log in where.
Past tests had produced long lists of “medium” findings. None looked urgent, so few were fixed. The red team budget (the budget for simulated real-world attacks) was limited. The client wanted to know which combinations of weaknesses actually led somewhere dangerous, and which only looked bad on paper.
How we mapped the paths
We built a map of the environment: users, computers, network connections, login sessions, permissions and known weaknesses. Then we asked the map one question. Starting anywhere an outsider could reach, what are the routes to the most critical systems?
For this client, those systems were the domain controllers (the servers that control every login), the core banking database, the plant control screens and the payment switch. We ranked each route by the number of steps, how likely it was to be noticed and which controls stood in the way.
We then tested the most serious routes for real, in a lab or staging environment, so production was never touched. Every step was mapped to MITRE ATT&CK, a public catalogue of attacker techniques, so the monitoring team could plan what to watch for.
The route we walked
We found 14 routes to the most critical systems and proved 3 of them from start to finish.
The one that caught the board’s attention began on the guest Wi-Fi. From there we reached the web control panel of an office printer. Through it we captured a staff login and replayed it (an NTLM relay attack), reached an administrator’s jump server, and read data from the core banking database in staging. Each of the six weaknesses along the way had been rated medium on its own.
Another route was shorter still. A service account had sweeping rights across the network, and its password sat in plain text inside a deployment script. Anyone who found that script could take over the whole Windows domain.
Two fixes that closed eleven routes
The map showed where routes crossed, so we could point to the choke points. Two changes broke 11 of the 14 routes. The first was turning on SMB signing, which stops captured logins from being replayed. The second was separating administrator accounts into tiers, so an account used on ordinary machines can never log in to critical servers.
Each of the three remaining routes needed four or more steps, and every step was a chance to catch an attacker. The client’s security operations centre tuned its alerts to watch those points.
For the board, a single diagram of the Wi-Fi route explained the risk more clearly than the long findings reports had. The client now re-runs the path map every month, and new routes are flagged when the infrastructure changes.
Organizations that fix findings one at a time and still feel exposed will usually learn more from mapping the routes between those findings.