Certified: The GIAC GCLD Audio Course

In this episode, we focus on privilege escalation in the cloud, because cloud compromises often become serious not at the moment of initial access, but at the moment an attacker turns a small foothold into broad control. Cloud identity and policy systems are powerful, flexible, and designed for rapid change, which is exactly why tiny mistakes can become ladders. When you understand common escalation patterns, you stop treating access policies as static documents and start treating them as active pathways that an attacker can traverse. This matters for exam scenarios because escalation often appears as a subtle misconfiguration rather than an obvious exploit. It also matters professionally because investigations frequently reveal that the attacker did not break encryption or bypass a firewall. They simply used permissions that were already there, combined with one or two allowed actions that let them expand access. The defensive advantage comes from recognizing those patterns before they are used against you.

Before we continue, a quick note: this audio course is a companion to our course companion books. The first book is about the exam and provides detailed information on how to pass it best. The second book is a Kindle-only eBook that contains 1,000 flashcards that can be used on your mobile device or Kindle. Check them both out at Cyber Author dot me, in the Bare Metal Study Guides Series.

Privilege escalation is gaining broader actions and resources than you were originally intended to have. In cloud environments, escalation is often expressed through permissions, roles, policy evaluation, and trust relationships rather than through exploiting a local operating system flaw. The attacker begins with an identity that can do something, then they use that ability to gain the ability to do more. Sometimes that means new actions, such as the ability to change configurations or create resources. Sometimes it means new scope, such as moving from one project to many, or from one resource group to the entire environment. Sometimes it means new identities, such as creating a new account with elevated privileges or impersonating an existing privileged identity. This definition matters because it makes you focus on effective permissions, not just declared permissions. Effective permissions are what actually happen when policy evaluation, inheritance, and trust rules are applied, and that is where escalation lives.

A recurring cloud risk is wildcard permissions and broad resource scopes, because these are convenient for teams and irresistible for attackers. Wildcards can appear in actions, resources, or both, and they often exist because someone wanted a role to just work across many services without constant updates. Broad scopes happen when a role is assigned at a high level, like an organization or subscription boundary, when it only needed to exist for one application. In isolation, a wildcard may not be fatal if the identity is tightly controlled and the resources are limited. In practice, wildcards are frequently paired with long-lived accounts, weak governance, and minimal monitoring, which turns convenience into a standing escalation path. Attackers love wide permissions because they reduce the need for creativity. If a compromised identity already has broad read access, the attacker can enumerate the environment quickly. If it has broad write access, the attacker can modify controls, create persistence, and expand reach with minimal friction. The core lesson is that scope is power, and wildcards silently multiply scope.

Policy inheritance is another pattern that creates hidden, unintended effective rights. Cloud policy systems often allow permissions to be assigned at multiple levels, such as organization, account, project, subscription, folder, group, or resource. Inheritance means a permission assigned at a higher level flows downward unless explicitly restricted, and that flow can create rights that are not obvious when you look at a single resource’s configuration. A team might review a project-level role assignment and conclude an identity is low privilege, while ignoring a higher-level group membership that grants powerful rights across many projects. Inheritance also interacts with default roles and built-in groups, where membership implies more access than the label suggests. This is why effective permissions analysis is different from reading a single policy document. The truth is the combination of all applicable policies and all identity relationships at evaluation time. Attackers exploit this because it allows them to hide in plain sight. They can operate with unexpected privileges that defenders do not realize exist until after the fact.

Role chaining through assume-role behaviors and token exchanges is a uniquely cloud-shaped escalation technique. Many cloud platforms allow an identity to assume another role under certain conditions, often controlled through trust policies and permissions that allow the action. This is a legitimate feature for delegation and temporary privilege, but it becomes a ladder when the allowed chains are not carefully controlled. An attacker who compromises a low-level identity might discover that it can assume a mid-level role, which can then assume a higher-level role, each step justified by a trust relationship that was designed for automation or cross-team access. Token exchanges can amplify the issue because tokens can represent different identities at different times, and the boundary between them can become unclear to defenders. The key point is that trust is a security boundary. If an identity can assume roles broadly, it can traverse boundaries that were meant to be separate. Threat modeling should include the question of what roles can be assumed from where, under what conditions, and with what evidence of legitimacy.

Workload identities and instance metadata are another common escalation path, especially when compute workloads run with powerful permissions by default. Many environments attach an identity to a workload so it can access storage, secrets, messaging, or other services without embedding credentials. This is a good pattern when permissions are minimal and access to identity credentials is controlled. It becomes risky when an attacker can reach the metadata service or otherwise extract tokens intended for the workload. If the workload is compromised through a web application flaw or exposed service, the attacker may be able to query metadata and obtain credentials that grant cloud API access. From there, the attacker can act as the workload identity, often with privileges broader than a human user would normally receive. This is why workload hardening and identity scoping must be treated together. The metadata endpoint is not just a convenience feature. It is a credential source, and credential sources must be protected as carefully as password vaults. When defenders forget that, escalation becomes a one-hop pivot from application compromise to cloud control plane abuse.

Permissions to modify policies, roles, or trust relationships are some of the most dangerous rights in any cloud environment, because they directly enable escalation and persistence. If an identity can edit a policy, it can grant itself more permissions. If it can modify a role assignment, it can attach powerful roles to itself or to another identity it controls. If it can change trust policies, it can allow new identities to assume privileged roles. These actions often look like legitimate administrative work, which makes them attractive to attackers who want to remain unnoticed. The exam mindset here is to treat permission management permissions as critical. Managing permissions is effectively managing power. Any identity that can grant or change access should be considered high risk and should require strong controls like separation of duties, approvals, monitoring, and limited scope. In cloud security, the ability to change IAM is often more dangerous than the ability to read data, because it can lead to everything else.

Overpowered service principals and forgotten automation accounts are a persistent source of escalation pathways. Automation accounts often start with broad permissions because they are created to solve a problem quickly, such as deploying resources, managing configurations, or rotating secrets. Over time, the scope remains broad even as the original need shrinks, and the account becomes a silent admin that is rarely reviewed. Service principals may also be used across multiple environments, which means a compromise in development can lead to production access. Forgotten accounts are particularly dangerous because nobody is watching them closely, and they may use long-lived credentials that are never rotated. Attackers love these identities because they behave like machines, which means their actions can be mistaken for normal automation. The defensive implication is that identity governance must include non-human identities with the same seriousness as human ones. If a service principal can create roles, modify policies, or access sensitive data broadly, it must be treated as a privileged identity with strict monitoring and lifecycle management.

A practical skill is reading an effective permissions story from logs, because logs are often where escalation becomes visible if you know what to look for. Instead of searching for a single smoking gun event, you look for a sequence: an identity authenticates, then performs enumeration actions, then attempts privilege-related changes, then accesses new resources that were previously out of reach. You may see actions that indicate role assumption, policy updates, group membership changes, or creation of new access keys. You may also see failed attempts that reveal the attacker exploring boundaries, which can be as informative as successful changes. The goal is to reconstruct how privileges changed over time, not just what data was accessed. When you can tell that story, you can identify the control that failed, the permission that enabled escalation, and the earliest point where detection could have interrupted the sequence. For exam questions, being able to identify the most relevant log category or the most suspicious administrative action is often the differentiator.

A common pitfall is reviewing policies without considering inheritance, which creates a false sense of safety. Teams will open a policy attached to a resource and see that it looks tight, then assume the resource is safe, even though an inherited role assignment at a higher scope grants broader access. This pitfall is especially common in environments with many projects and shared groups, because permissions are often granted through group membership rather than direct assignment. It is also common when built-in roles are used without fully understanding what they include. The defensive correction is to make effective access review the standard, not policy review in isolation. Effective access review means you evaluate the identity’s permissions as the platform enforces them, taking into account all group memberships, inherited grants, role assumptions, and trust relationships. If you do not do this, you will miss the very escalation paths attackers depend on, and your incident response will start from the wrong assumptions.

A quick win that reduces escalation risk broadly is least privilege combined with frequent access review. Least privilege is not a one-time design project; it is an operational practice where permissions are continuously reduced to what is needed and nothing more. Frequent access review matters because environments drift, teams change, and emergency grants become permanent. Reviews should include both human and non-human identities, and they should focus on high-risk permissions like policy modification, role assignment, and broad data access. Least privilege also works best when roles are scoped tightly and separated by function, so that a workload identity can perform its job without gaining administrative reach. When reviews are frequent, you catch privilege creep before it becomes normal. When least privilege is enforced, an attacker who compromises an identity has fewer steps available for escalation. The combined effect is that your environment becomes harder to climb, even if a foothold is obtained.

Now rehearse a scenario where an attacker adds itself to an administrative group, because this is a clean illustration of cloud privilege escalation. Imagine an attacker compromises a mid-level identity that has permission to manage group membership, perhaps because it belongs to an operations team or because it supports a workflow like user provisioning. The attacker uses that permission to add their identity, or a newly created identity, to an admin group that has broad control across the environment. From that moment, escalation is complete, and subsequent activity can look like ordinary admin work. The controls that should stop this include minimizing who can change group membership, requiring approval workflows for privileged group changes, alerting on group membership modifications, and limiting the scope of groups so membership does not automatically imply full admin across everything. You also want rapid response capability, such as immediately removing the identity and investigating the full set of actions taken since the change. This scenario highlights why identity management permissions are so sensitive. The ability to change group membership is effectively the ability to grant power, and attackers know it.

Use a memory anchor to keep the escalation concept clear: ladders built from small rungs. In cloud, attackers rarely jump directly from low privilege to full admin in one dramatic move. They climb using small permissions that look harmless on their own, like the ability to read configuration, assume a role, query metadata, or update a group. Each small permission is a rung, and the ladder is the chain that connects them. Your job as a defender is to break ladders by removing unnecessary rungs, narrowing scope, and monitoring the few rungs that must remain. When you look at a role, do not just ask what it can do today. Ask what it can become if combined with one other permission or one inherited grant. This mindset turns privilege escalation analysis into a practical review activity rather than a theoretical fear.

As a mini-review, keep the main cloud escalation patterns organized. Escalation is gaining broader actions and resources, usually through identity and policy pathways rather than host-level exploits. Risky wildcards and broad scopes create silent power that attackers can use immediately. Policy inheritance can create hidden effective rights that are not obvious when reviewing a single resource. Role chaining through assume-role actions and token exchanges can allow attackers to traverse trust boundaries step by step. Workload identities and instance metadata can provide credentials if a workload is compromised, enabling control plane abuse. Permissions to modify policies, roles, or trust are direct escalation levers and should be tightly controlled and monitored. Overpowered service principals and forgotten automation accounts often hold dangerous privileges without scrutiny. Reading logs as a sequence helps you reconstruct how privileges expanded, while the pitfall is ignoring inheritance. The quick win is least privilege plus frequent review, and the ladder anchor helps you remember how small permissions become big outcomes.

To conclude, cloud privilege escalation is often a policy and identity story, not a software vulnerability story, which is why small mistakes can have outsized consequences. When you recognize patterns like broad scopes, inheritance, role chaining, workload identity abuse, and permissions that allow access changes, you can find and remove ladders before attackers climb them. When you treat service principals and automation accounts as privileged identities, you reduce hidden risk that attackers love to exploit. When you read logs for an effective permissions story, you improve both detection and investigation speed. Use the ladder memory anchor to stay focused on how rungs connect, and then apply that discipline in a tangible way. Audit one role for escalation pathways.