The Initial Alert: A Compromised Service Principal
The incident doesn’t start with a bang, but a whisper. An automated alert flags unusual activity: a service principal—an identity used by an application—is accessing resources outside its normal pattern. In theory, your RBAC policies should limit the potential
damage. This service principal only has the "Reader" role at a specific resource group scope, meaning it can see resources but not change them. The problem is, an attacker who compromises even a low-privilege account can use that visibility to map your environment, identify valuable targets, and find the next weak link. The security team’s first step isn’t panic; it’s investigation. They use Azure’s activity logs to trace every action the compromised identity has taken, confirming the principle of least privilege has at least limited the initial blast radius. The attacker can look, but for now, they can't touch.
The Pivot: Exploiting Overly Broad Scope
Here’s where things get real. The attacker, using their read-only access, discovers another identity: a developer account that was mistakenly assigned the "Contributor" role at the subscription level. This is a classic misconfiguration. The developer only needed access to a single development resource group, but for convenience, they were given permissions across the entire subscription. The attacker now pivots from the limited service principal to this powerful user account. The difference is critical. "Contributor" allows the creation and management of most resources. Suddenly, the attacker goes from being a window shopper to having the keys to the store. They can't manage access or assign roles to others—that requires the "Owner" role—but they can deploy new virtual machines, alter network settings, and potentially access data stored in a variety of services. The overly broad scope of this single role assignment has turned a minor issue into a major security event.
Containment: Where Good RBAC Shines
The security team detects the attacker’s new activity and initiates containment procedures. This is where a well-planned RBAC strategy pays dividends. The incident response team uses accounts with just-in-time (JIT) privileged access, requested via Privileged Identity Management (PIM), to assume temporary, high-privilege roles. They don’t use standing "Owner" accounts for daily work, which itself is a security best practice. Their first move is to disable the compromised developer account. Next, they use their elevated RBAC permissions to revoke the attacker's access and begin remediation. Because their permissions are correctly scoped, they can surgically remove the malicious infrastructure the attacker deployed without disrupting the entire production environment. They also have custom roles, like a "Forensic Investigator" role, that grants read-only access across all subscriptions in the management group, allowing them to investigate the full extent of the breach without granting dangerous write permissions.
The Post-Mortem: Lessons from the Trenches
After the dust settles, the review begins. The incident revealed two critical flaws. First, the subscription-level "Contributor" role was a case of excessive privilege born from convenience. The fix: that role was removed and replaced with a custom role granting only the necessary permissions, scoped to the specific resource group the developer actually needed. Second, the initial compromise highlighted the need for better monitoring of service principal behavior. The key takeaway is that RBAC isn't a "set it and forget it" tool. It requires constant auditing and refinement. Role assignments, especially highly privileged ones like Owner and Contributor, should be rare, justified, and scoped as narrowly as possible. Using groups to assign roles instead of individual users simplifies management and reduces the chance of a forgotten permission becoming a backdoor.
