The breach nobody approved

Why adopting Copilot—and doing it right—can’t wait

Nobody granted an attacker access to your most critical systems. Your organization granted six people access to six other things and the math did the rest.

That describes most identity-driven breaches worth studying. There is no zero-day, no malware detonation and no alert that fires. There is only a sequence of access decisions—each one defensible on the day it was made, each one approved by someone competent—that quietly assembled into a route.

The executive problem is subtle. Your security program measures the individual decisions, not the sequence. Every control in your stack evaluates permissions one at a time. Attackers evaluate them as a chain. Here is what that chain looks like in practice.

It starts with an account that passes every check

A service desk technician. Multi-factor enrolled, no local administrator rights on her own machine, a clean access review signature from last quarter. Hers is the most audited and least suspected seat in the building.

What her team can do is reset passwords for users who lock themselves out. Mundane enough that it barely registers as a privilege. But the delegation was never scoped to one slice of the directory. It was granted across all of it, maybe on a Friday in 2019, by someone who needed a ticket closed and knew the correct version of the change would take three days.

Phish her and you do not get administrative access. You get something better: the ability to become other people.

Access outlives the reason it was granted

Every environment has an attic. In this one it holds a deployment group built for a Windows migration that wrapped in 2021 and was never closed out. Five years on, it still carries local administrator rights on roughly 4,000 workstations.

Three of its four members have since left. The fourth is a contractor whose account stays enabled because a scheduled task references it and no one wants to discover what breaks if it stops. That is the account our attacker takes, and with it most of the workstation fleet. The migration has been over for years. Its permissions are still working the day shift.

Then a deadline meets a policy

Four thousand machines matter because of who signs into them. Last Tuesday a database administrator remoted into a user’s desktop to untangle a report that would not run. Ten minutes, problem solved, everyone grateful.

Your tiering policy says privileged accounts never touch general-purpose endpoints, and your tiering policy is right. It is also a document, and the report was due. Credentials linger in memory long after the helpful moment passes, and our attacker already owns that desktop.

Where on-premises quietly becomes cloud

The database administrator is not a domain admin either. But her account sits in a group with broad rights over a directory container, and that container syncs to your cloud tenant carrying global administrative entitlement—a bridge built during a hybrid identity project by an engineer who has been gone two years.

Four moves: service desk, to workstation fleet, to directory, to cloud tenant. No exploit, no malware and no alert, because none of it required any. This is what lateral movement looks like when permissions do exactly what they were configured to do in an order no one designed. The path was fully formed and fully walkable for years. It was simply never drawn.

Every identity has value. The question is to whom

Employees, contractors, service accounts, applications and cloud resources all represent trusted access to business-critical systems. As organizations adopt more cloud services, automation and AI, the number of identities keeps growing and so does the number of ways they connect. The scenario above needed four steps. Most environments offer far more, and the ones that matter are rarely on a privileged access list.

Rather than exploiting software vulnerabilities, today’s threats often target legitimate identities with existing access, which lets them move through an environment undetected. Identity risk isn’t always visible, which is precisely why it accumulates.

Why your existing investments missed it

When attackers gain control of an identity they inherit the trust attached to that account, which lets them operate as legitimate users and bypass controls built to stop external threats. The uncomfortable part is not that the path existed. It is that a mature security program was running the entire time.

• Vulnerability management scanned every system in the chain and found nothing, because nothing in the chain was a vulnerability. Patch levels were current. The path was built from permissions and permissions do not have CVEs.
• Identity governance certified every access grant involved. As typically configured, access reviews ask whether a person should hold an entitlement, one row at a time, answered by managers who see a group name and not its downstream reach.
• Privileged access management protected the accounts labeled privileged. The database administrator was not in that category, because privilege had been defined by job title rather than by what the account could actually reach.
• Multi-factor authentication was enforced and did its job. It made the initial compromise harder and was irrelevant to everything after it, which used stolen credentials and legitimate directory operations.

Each control answers a real question correctly. None answers the question that decides whether you get breached: if this identity is compromised, what can it reach and by what route?

The number that belongs on your board slide

Attack paths converge. In a typical enterprise, tens of thousands of theoretical routes funnel through a small number of relationships: the nested group, the overly broad delegation and the forgotten sync configuration. These are critical choke points and they are where the leverage lives. Fixing the wrong permission eliminates one path. Fixing a choke point eliminates thousands.

That reframes identity risk from an unbounded cleanup project into a prioritization problem with a finite, defensible answer. The question stops being how to remediate tens of thousands of excessive permissions, which no CISO can resource and no board wants to hear. It becomes which handful of changes collapse the majority of paths to your most critical systems. That question has an owner, a timeline and a measurable result, and you can answer it without asking for headcount.

The real question isn’t “who has access?”

It’s “if an attacker compromises this identity, what can they actually reach?”

Most identity programs are built around governance: who should have access and whether you can prove you reviewed it. That work is necessary and it satisfies auditors. It does not tell you whether an attacker can reach your general ledger from a contractor laptop.

Answering that means seeing your environment as a graph of relationships rather than a roster of accounts. Rather than simply showing who has access, SpecterOps shows how that access chains together to reach critical systems, surfacing hidden attack paths, excessive permissions, identity exposure and the critical choke points where remediation pays off. ConRes brings the engineering side: assessing your posture, implementing SpecterOps effectively, reducing unnecessary access, strengthening least-privilege and Zero Trust strategies and folding identity into your broader security program rather than beside it.

Attackers have already run this analysis on environments like yours. The only real question is whether you see the paths first.