Privileged Access: Where Identity and Infrastructure Meet

Privileged access is the point where an identity decision becomes control over infrastructure. A role assignment, a group membership or an approved session decides who can delete a backup, encrypt a datastore or change what the rest of the security stack can see. Identity teams usually govern one half of that and infrastructure teams secure the other. Attackers treat it as one path.

Why attackers aim here

Mandiant’s latest M-Trends report describes ransomware operators, including those behind Akira and Qilin, going after backup infrastructure, identity services and virtualization management planes. Encrypting a hypervisor’s storage layer makes every virtual machine on it fail at once. In some cases, misconfigured certificate templates in Active Directory Certificate Services were used to create administrator accounts that sat outside password rotation. Mandiant’s advice is to treat virtualization and management platforms as Tier-0 assets and to decouple backups from the corporate directory.

The human route to the same place is just as direct. CISA and the FBI document help-desk impersonation in which a caller talks staff into resetting a password or MFA method. One successful call on the right account turns into administrative reach.

In both cases the attacker is not defeating technology. They are using access that the environment grants to a small set of identities, and that set is larger than most organizations assume.

Where infrastructure privilege hides

Four ways excess privilege builds up

1. Standing access. Administrator rights stay on because turning them on takes time. A stolen standing credential works at any hour.

2. Paths, not accounts. Privilege reaches people through nested groups, inherited cloud roles and delegated rights. A review of the account list misses the route. The better questions are who can grant privilege, who can change federation, who can edit conditional access, and who can modify certificate templates.

3. Shared and emergency accounts. Break-glass accounts are necessary. They are also rarely tested, rarely monitored, and often left unchanged after use.

4. Mixed-use endpoints. An administrator who reads email and browses the web on the machine that holds high-privilege tokens gives an attacker the shortest possible path.

NIST SP 800-53 frames the discipline as least privilege (control AC-6). Its enhancements cover restricting privileged accounts, requiring non-privileged accounts for everyday work, logging the use of privileged functions and reviewing privileges on a schedule. The framework is clear on what to do. The difficulty is applying it to the paths above.

Design decisions and their costs

1. Define the top tier by capability, not by name. Anything that can control identity, the cloud control plane, virtualization, backup or security tooling belongs in the highest tier. Cost: the tier is larger than people expect, and system owners will push back.

2. Separate administrator identities and devices. Dedicated accounts with no email, used from hardened workstations or through brokered sessions. Cost: more accounts to govern and daily friction for administrators.

3. Replace standing access with time-bound elevation. Just-in-time access with approval and automatic expiry. Cost: it slows incident response unless emergency elevation is designed and rehearsed, and approvals turn into rubber stamps when volume is high.

4. Require phishing-resistant MFA on privileged and remote-access paths. The Scattered Spider advisory points to FIDO/WebAuthn and PKI-based MFA. Cost: hardware and enrollment effort, and a recovery process that must be as strong as the login.

5. Protect the grant path. Require approval and raise alerts for changes to role assignments, federation, conditional access policy and certificate templates. Cost: change friction on tasks that were previously informal.

6. Limit where management interfaces can be reached. Administrative consoles should answer only to administrator networks or brokered gateways, never to general user networks. Cost: network and tooling changes, and some legacy systems that cannot comply.

7. Secure the access tooling itself. Vaults, privileged access platforms and remote support tools hold or broker the keys. Patch them quickly, monitor them closely, and keep them out of the identity domain they protect where you can. Cost: they become a high-value operational dependency.

How these controls fail

• The vault sits in the same directory it is meant to protect, so compromising the directory compromises the vault.

• Just-in-time approvals are granted automatically or in bulk.

• Break-glass accounts exist with no alert when they are used.

• Access reviews certify accounts but never the paths that confer privilege.

• Exceptions are granted with no owner and no expiry.

Measures that show progress

• Standing entitlements on the highest-tier systems.

• Share of privileged sessions that are brokered and recorded.

• Number of identities able to grant privilege.

• Age of the oldest unused administrative entitlement.

• Break-glass uses, each with a reviewed reason.

First moves

1. List every identity and role that can control directory, cloud, virtualization and backup. Include who can grant those rights.

2. Remove standing access from that list and put expiry on what remains.

3. Place administrative consoles behind a dedicated access path.

4. Alert on changes to role assignment, federation and certificate templates.

5. Test break-glass access, then rotate it and confirm that someone is alerted when it is used.

Privileged access is neither an identity problem nor an infrastructure problem. It is both, and the control belongs where they meet.

Sources

1. Google Cloud / Mandiant — M-Trends report, latest edition

2. CISA and FBI — Scattered Spider joint cybersecurity advisory

3. NIST — SP 800-53 Rev. 5, Security and Privacy Controls (AC-6, Least Privilege)

4. NIST — SP 800-207, Zero Trust Architecture