MSSQL and SCCM privilege escalation expose role model flaws

At a glance

What this is: NHI Mgmt Group's analysis, drawing on SpecterOps's blog post: MSSQL and Microsoft Configuration Manager permission models contained elevation paths that let lower-privileged principals reach top-tier administrative roles.

Why it matters: This matters because identity governance for admin roles is only as strong as the underlying permission model, and hidden escalation edges can defeat least privilege even in heavily used enterprise platforms.

By the numbers:

• The MSSQL flaw had existed since SQL Server 2005, according to SpecterOps.
• The SCCM issue affected versions 2403 through 2503, according to SpecterOps.
• Microsoft reduced response times from 28 and 127 days to 14 and 7 days when disclosure timelines were provided, according to SpecterOps.

Context

Permission models can create hidden privilege pathways when a role is documented as limited but still carries a route to higher authority. In mixed-mode SQL Server and in Configuration Manager role administration, the real risk is not the named permission alone but the effective ability to cross into a more powerful role without a separate approval boundary.

These are classic governance failures in enterprise admin design: the delegated role looks scoped, yet it still permits actions that rewrite who controls the platform. For identity teams, the lesson is that privilege boundaries must be validated against actual role interactions, not assumed from role labels alone.

Key questions

Q: How do privilege escalation flaws emerge in role-based admin systems?

A: Privilege escalation flaws emerge when a role contains permissions that can chain into higher control, such as changing roles, granting access, editing policies, or creating new admins. In role-based admin systems, the problem is often indirect privilege, where a seemingly limited admin role can combine multiple allowed actions into full control over users, data, or configuration.

Q: Why can delegated admin roles become self-escalation paths?

A: Delegated admin roles can become self-escalation paths when the delegated account can change its own scope, assign privileges to itself, or use a management action that ultimately grants broader authority. The risk is strongest where delegated admin roles include role assignment, consent, token issuance, or policy editing without separate approval or boundary checks.

Q: What is the difference between least privilege and effective privilege?

A: Least privilege is the design principle of giving only the minimum access needed for a task. Effective privilege is the access a person or system can actually exercise after inherited roles, group memberships, temporary grants, delegated rights, and privilege chaining are taken into account, which is often broader than the intended least-privilege baseline.

Q: How should teams validate whether an admin role can reach full control?

A: Teams should validate admin reach by tracing effective permissions from the role to every inherited group, policy, API permission and delegated grant, then testing whether the role can change its own membership, elevate privileges, or bypass approvals. A complete permission graph exposes hidden privilege paths, transitive access and mis-scoped standing rights.

Technical breakdown

How MSSQL password-reset permission becomes full server control

In MSSQL, ALTER ANY LOGIN sounds like a narrow administrative permission, but it can become an escalation primitive when a target login belongs to securityadmin or has IMPERSONATE ANY LOGIN. If a principal can reset passwords without supplying the old password, it can sidestep the intended gate and then use the newly obtained login to reach sysadmin or equivalent authority. The important point is that privilege is not just a label on the source account. It is the combination of available actions, target role membership, and whether the control logic checks the right preconditions.

Practical implication: Model the permission graph for role-switching paths, not just direct grants, and treat password-reset capability as an escalation control point.

Why SCCM role administration can widen beyond its stated purpose

Configuration Manager security roles are often described by their intended task, but the effective permission set can include administrative actions far beyond that task. In the case described by SpecterOps, a role meant to run CMPivot also had the ability to modify users and security roles, which meant the role could rewrite its own scope and inherit broader authority. This is a governance failure in role composition, not a flaw in the idea of delegated administration. When a limited admin role can edit assignments, the role boundary becomes self-defeating. See the UEM Buyer's Guide.

Practical implication: Review delegated roles for self-escalation paths and remove any permission that lets a task-scoped role alter its own grants.

Why attack-path analysis surfaces privilege escalation that consoles hide

Tools that model permissions as a graph can expose escalation edges that the administrative console does not make obvious. In this case, the relevant question is not whether a role appears constrained in the UI, but whether there exists a sequence of legitimate permissions that produces higher authority than intended. Graph analysis is useful because it turns nested permissions, inheritance, and role membership into traversable relationships. That makes it easier to see where a permission model contains an unexpected bridge from routine administration to complete platform control.

Practical implication: Use graph-based review to test whether a documented role can reach a more privileged role through ordinary permission transitions.

Threat narrative

Attacker objective: The attacker’s objective is to convert a limited administrative foothold into complete control of the database instance or management hierarchy.

1. Entry begins with a principal that already holds an administrative permission such as ALTER ANY LOGIN or membership in a scoped Configuration Manager role.
2. Escalation occurs when that permission is used to change credentials or modify role assignments, creating a path into securityadmin, sysadmin, or Full Administrator authority.
3. Impact follows when the actor can fully control the SQL Server instance or the Configuration Manager hierarchy, including actions that extend to system-level abuse.

Breaches seen in the wild

• Azure Key Vault Contributor escalation 2024: Datadog found Azure Key Vault Contributor could add itself to access policies and read every secret, key and certificate in a vault.
• Malwarebytes breach 2021: SolarWinds attackers added a certificate to a dormant email security app's service principal at Malwarebytes and read internal email via Microsoft Graph.

Read and download The State of NHI & AI Agent Breach Report 2026, covering 200+ breaches impacting Non-Human Identities including AI Agents.

NHI Mgmt Group analysis

Hidden escalation edges matter more than the nominal role name. Both issues show that enterprise platforms can document a role as limited while still permitting an authority jump through adjacent permissions. That is a governance failure in role design, because the effective power of a role is determined by what it can reach, not by how it is described. Practitioners should audit permission graphs for transitive authority, not just review direct grants.

Role composition can become a self-escalation mechanism. A delegated admin role is only safe when it cannot rewrite its own membership, scope, or downstream grants. SpecterOps's findings show that once a task-specific role can alter users or related roles, the boundary between scoped administration and full control collapses. This is the exact kind of hidden privilege bridge that privileged access management programmes must be designed to uncover.

Legacy platforms still carry modern governance debt. MSSQL and Configuration Manager are not edge cases, they are the kind of widely deployed systems where old permission assumptions survive for years. The MSSQL flaw existing since SQL Server 2005 is especially telling: mature software can preserve escalation logic long after teams assume the model has been settled. The practical takeaway is that age does not reduce governance risk; it often hides it.

Attack-path visibility is now a control requirement, not an analyst convenience. SpecterOps's own graph-based research approach demonstrates why role abuse is so often discovered late. When privilege boundaries are encoded as traversable relationships, the control objective is to detect reachable authority, not merely assign a role label. Teams that cannot answer who can reach sysadmin or Full Administrator through normal permission transitions do not truly understand their admin estate.

Least privilege fails when roles can modify their own enforcement layer. The core lesson across both flaws is that least privilege is not a static assignment problem. It is a continuing validation problem across delegation, inheritance, and permission mutation. Practitioners need to treat role-editing ability as a governance red flag because it can erase the very constraint the role was supposed to impose.

What this signals

Permission graphs are now the practical unit of review. A role can look acceptable in a console and still carry enough adjacency to become a platform-wide escalation path. For IAM and PAM teams, that means governance has to move from static role review to reachability review, especially where admin tasks can mutate other permissions.

Legacy administrative surfaces deserve periodic reclassification. Older platforms often preserve permission logic that predates current governance expectations, which means the control model can drift away from the documented intent. Teams should treat long-lived administrative technologies as candidates for recurring attack-path validation, not one-time hardening.

Self-modifying admin roles are a control smell. If a role can edit the users, scopes, or permissions that govern it, the role can become its own escalation mechanism. That pattern is especially dangerous in delegated administration designs because the control layer and the subject of control become the same thing.

For practitioners

• Audit transitive privilege paths Map whether any administrative permission can reach sysadmin, Full Administrator, or equivalent platform-wide authority through normal role transitions.
• Remove role self-edit capabilities Strip any permission that lets a task-scoped admin role change its own users, scope, or assigned security roles. See the Privileged Access Management Guide.
• Test password-reset gates as escalation points Validate whether password change logic checks the full target-role context, especially for privileged logins and impersonation-capable accounts.
• Review legacy admin models for hidden bridges Reassess older platform roles where documentation and actual permission effects may have drifted apart over time.

Key takeaways

• The two flaws show that a limited admin permission can still become a route to complete control when the role model contains hidden transitions.
• SpecterOps ties the MSSQL issue to a long-lived permission pattern and the SCCM issue to a role that could modify its own scope.
• The control that matters most here is reachability analysis across roles, memberships, and credential-changing actions, not just direct permission review.

Related NHI Mgmt Group resources: Privileged Access Management Guide · Just-in-Time Access and Zero Standing Privilege Guide · Microsoft Configuration Manager Security Guide

Key terms

• Privilege Escalation: An attack technique where a compromised identity, often an NHI with initially limited permissions, exploits vulnerabilities or misconfigurations to gain elevated access rights, typically leading to broader compromise.
• Role-Based Access Control: A model that grants permissions by assigning identities to predefined roles. It works well when jobs are stable and access patterns are predictable, but it becomes brittle when exceptions pile up. In practice, role design must stay small enough to audit and broad enough to avoid endless custom variants.
• Delegated administration: Delegated administration allows local operators to make approved configuration changes without waiting on a central platform team. It improves speed, but it only remains safe when permissions are narrow, changes are logged, and validation prevents policy drift.
• Attack Path Analysis: Attack Path Analysis is the process of mapping how an attacker could move from an initial foothold to a valuable target. It examines identities, permissions, network reachability, misconfigurations, and trust relationships to identify realistic routes of compromise. The goal is to prioritize controls that break the shortest and most likely paths.

Deepen your knowledge

NHI governance, agentic AI identity, and machine identity lifecycle are core topics in our NHI Foundation Level course, the industry's only accredited NHI security programme. If you are building or maturing an IAM programme, it is worth exploring.