IAM misconfiguration in the cloud

Objective 4.5 in this course covers cloud-based attacks — container escapes, metadata service attacks and IAM misconfiguration. This is the applied lab for the objective. Runs against your OWN cloud tenant, enumerating your own permissions, in the lab from lesson 2. The provider owns the platform, so lesson 4's rules apply.

Why this matters

In the cloud, identity and access management is the perimeter. There is no network edge to hide behind; what an identity can do is defined entirely by its policies, and the misconfigurations there are the cloud equivalent of every access-control flaw in this course combined.

It is named by CompTIA, and it is where lesson 33's stolen credentials become serious: a metadata credential is only as dangerous as the role's permissions, and IAM misconfiguration is what makes those permissions dangerous.

The lesson

Over-broad policies and wildcard permissions

The most common cloud finding, and the easiest to introduce:

• Wildcard permissions. A policy granting all actions, or all actions on all resources, because scoping it precisely was harder than using the wildcard. This is the cloud "everyone/full-control" and it is everywhere.
• Unused broad grants. An identity granted wide permissions for a task it did once, never narrowed afterwards.
• Broad managed policies attached for convenience where a narrow custom policy was needed.
• Permissions that seem narrow but are not — a single permission that allows granting further permissions is equivalent to full control, and there are several of these that do not look powerful until you trace what they enable.

The assessment method is enumeration: determine what an identity can actually do, compare it with what it needs, and the gap is the finding. Lesson 15's coverage thinking applies — what you did not enumerate, you did not assess.

Role assumption chains and privilege escalation paths

Cloud escalation is rarely a single over-broad policy; it is a chain of identities, each able to become or grant to the next.

• Assume-role chains. Identity A can assume role B, which can assume role C, which is an administrator. No single step looks alarming; the chain is the escalation.
• Permission to modify policies. An identity that can edit its own or another's permissions can grant itself anything — the escalation is one self-modification away.
• Passing a role to a service. Permission to hand a powerful role to a service you can run lets you inherit that role's power.
• Trust relationships that are too open — a role that trusts a broad set of principals to assume it, including ones an attacker can reach.

This is lesson 40's chain in cloud form, and it is exactly why individual permissions must be assessed for what they enable, not just what they directly do. Tooling exists to map these chains, and reading its output is the skill — lesson 18's rule that a tool's finding is a lead applies.

Public storage and the access nobody intended

The finding that reaches the news, and the simplest:

• Storage exposed publicly by a permissive access setting, holding data nobody meant to publish — backups, customer data, credentials, source.
• Overly broad sharing short of fully public but wider than intended — shared with an entire organisation, or with any authenticated user of the whole platform rather than the specific account.
• Snapshots and images made public, which frequently contain credentials and data from when they were taken.
• Logging and configuration data exposed, which reveals the environment even when the primary data is protected.

These are discovered by enumerating what is reachable and checking each store's access setting against intent, and they are reported on discovery — the exposure is the finding, and reading the exposed data beyond confirming the exposure runs into lesson 4's minimum-necessary rule.

Enumerating your OWN tenant's permissions

The applied lab for objective 4.5, and the rule in the heading is not decoration: you enumerate your own tenant.

1. Create identities with deliberate misconfigurations — a wildcard policy, an assume-role chain, an over-broad trust, a public storage setting.
2. From a starting identity, enumerate what it can do, using the platform's own permission-query capabilities and the mapping tooling.
3. Find the escalation path you planted — the chain, or the self-modification — from the enumeration rather than from memory.
4. Demonstrate reaching administrator, then narrow the policies and confirm the path closes.
5. Check your storage exposures and correct them.

The discipline that transfers to engagements: enumerating permissions is active reconnaissance against the identity system, and it stays inside the account you are authorised for. Enumerating another tenant's permissions, or a provider's, is out of scope exactly as scanning a third party is — the cloud does not change lesson 3.

Least privilege that survives a real deployment

Remediation at the cause, and honest about why it is hard:

• Least privilege is the whole answer, and it is genuinely difficult, because determining the minimum an identity needs requires understanding what it does — which is why wildcards proliferate.
• Use the platform's tooling that observes actual usage and proposes tightened policies from it, turning "what might it need" into "what did it use".
• Eliminate the escalation primitives specifically — the permissions that grant permissions, the over-open trust relationships — because these are higher-impact than a broad read grant and are easy to overlook.
• Separate duties and tier, as on-premises: the identity that runs the workload is not the identity that administers the account.
• Continuously check, because cloud environments change constantly and a configuration correct today drifts — which is the re-test criterion lesson 41 asks you to agree.

The client message: in the cloud, least privilege is not hardening on top of a perimeter — it is the perimeter, and the findings here are not edge cases but the central control of the whole environment.

What to take into the exam

• In the cloud, IAM is the perimeter; what an identity can do is defined by policy, and misconfiguration there is the core finding.
• Wildcards and unused broad grants are the common over-permission; a permission that grants further permissions is equivalent to full control.
• Escalation is usually a chain — assume-role chains, self-modification, role-passing, over-open trust — so assess permissions for what they enable.
• Public storage is the simplest and most damaging exposure; report on discovery.
• Enumerate only your own tenant; least privilege is the fix and is the environment's central control, not an add-on.