15.1 IAM Misconfiguration, Metadata Service, and Exposed Storage

Domain 4, Attacks and Exploits, is 35 percent of CompTIA PenTest+ PT0-003. Objective 4.6 — Given a scenario, perform cloud attacks using the appropriate tools — is the cloud matching drill. You already have a scoped cloud estate from pre-engagement. Now you pick the attack type that fits the misconfiguration, then the tool family that belongs. This section covers IAM misconfigurations, metadata service attacks, trust relationship abuse, resource misconfiguration (network segmentation, network controls, IAM credentials, exposed storage buckets, public access to services), logging information exposure, and third-party integrations. Container escape, image and artifact tampering, supply chain, workload runtime, and the named tool table — Pacu, Docker Bench, Kube-hunter, Prowler, ScoutSuite, and cloud-native vendor tools — belong in the next section. Domain 4 is not Domain 3: a Prowler or ScoutSuite row is a hypothesis until you use the hole. It is also not Domain 1: shared responsibility told you who you may test; 4.6 is how you abuse what the customer left open.

Shared responsibility recap: hypervisor out, customer config in

The shared responsibility model from objective 1.1 still binds every 4.6 stem. The hosting provider owns the facility, the physical hardware, and the hypervisor. Other tenants on the same physical host are not in your statement of work (SoW). You do not 'escape the hypervisor' because an Amazon EC2 instance, Azure VM, or Google Compute Engine VM is in scope. What is usually in scope — unless the rules of engagement (RoE) say otherwise — is customer-configured identity, storage, network, and application material: IAM policies and keys, bucket and blob ACLs, security groups / network security groups, guest OS and app credentials, and the code they deployed.

Check the provider's testing terms of service before you treat a production cloud account as a free-fire range. Many providers allow testing of the customer's resources and still forbid attacks against the control plane they operate. Exam trap: answering 'attack the hypervisor' when the stem shows a public bucket or a wildcard IAM policy. Trap two: treating a SaaS identity provider or a CDN the customer uses as automatically in scope. That is a third-party conversation, covered later in this section, not a license to pentest Microsoft or Cloudflare because the app federates there.

IAM misconfigurations: policies, keys, and console MFA

IAM misconfiguration is the identity layer of cloud attacks. CompTIA groups it with IAM credentials under resource misconfiguration because the resource being abused is often the policy or the key, not a memory-corruption CVE.

Over-permissive policies. The classic picture is Action: * on Resource: *, or the Azure / GCP equivalent of a role that is Owner or Editor on a whole subscription or project. A developer role that can also create access keys, pass any role, or assume every role in the account is an escalation path, not a convenience. When you pick it: a stem shows a policy that grants far more than the job needs, a user who can attach an administrator-equivalent policy, or a service account with project-wide edit.

Unused access keys. Long-lived IAM user access keys that nobody rotated, keys created years ago, and keys that still work after the human left are IAM credential findings. The attack is using a live key that should not exist, not brute-forcing the console password. Instance roles issue short-lived credentials through metadata; unused user keys sit in a profile or a CI secret for years. Exam trap: treating unused keys as 'only a compliance checkbox.' On 4.6, a live unused key is authentication material — adjacent to pass-the-token thinking from 4.3, scored here as cloud IAM.

No MFA on the console. Root or highly privileged console users without multi-factor authentication are an IAM misconfiguration. Password spraying a console login is 4.3-adjacent; the cloud finding CompTIA wants is that the account allowed a single factor on the control plane. Testers report the missing MFA. They do not publish a password list.

When you pick IAM: the stem is about who can do what in the account — policies, keys, console factors — not about a public object in a bucket (that is exposed storage) and not about a container that can see the host (that is 15.2).

Trust relationship abuse and the confused deputy

Trust relationship abuse is IAM's cross-account and cross-service cousin. A role's trust policy (who may assume the role) or an equivalent Azure Lighthouse / GCP IAM binding says which other principals may act as that role. If the trust is a wildcard principal, or an entire other cloud account the customer does not control, any principal that can call assume-role from that trust path becomes the role.

Confused-deputy is the pattern where a privileged service is tricked into using its permissions against a resource the caller should not reach. The deputy — a build service, a logging service, a vendor integration — is more privileged than the attacker. The attacker does not steal the deputy's key; they coerce the deputy into touching a bucket, queue, or account the attacker named. Identification on the exam: look for a trust that is too broad, a missing source-account or source-ARN style condition, or a third-party app the org authorized to 'act as' the company.

When you pick it: the stem is two accounts, a role trust, a vendor that can assume a role in the customer account, or 'the CI system was allowed to deploy anywhere.' When you do not: a local container breakout (next section) or a public website with no identity federation.

Metadata service attacks: 169.254.169.254 as the exam identifier

Cloud compute instances query a metadata service for hostname, userdata, and — critically — the instance role credentials the provider injected. On AWS, the classic exam identifier is the link-local address 169.254.169.254 (Instance Metadata Service, IMDS). Other clouds use a similar link-local or special-IP metadata endpoint. You do not need a live curl recipe against a real account, and this guide will not give one.

What it does: if a process on the instance, or a server-side request the instance makes, can read the metadata document, it can retrieve temporary credentials for the instance profile. Those credentials are IAM. From there the tester has whatever the role was granted — often object storage, instance management, or even IAM itself.

How the exam gets there. Two pictures:

1. SSRF from objective 4.5: a web app on the instance is tricked into requesting the metadata address. The application server, not the tester's laptop, can reach 169.254.169.254.
2. Compromised workload: a foothold on the VM or container already runs on the instance, so it can query metadata the same way the legitimate agent does.

When you pick it: the stem mentions instance metadata, IMDS, 169.254.169.254, 'role credentials from the instance,' or an SSRF that targets link-local. Exam trap: treating metadata SSRF as a 4.5-only item. 4.5 named SSRF as an application attack. 4.6 names metadata service attacks as the cloud impact of that SSRF (or of a compromised workload). If the goal is 'steal the instance role,' the 4.6 answer is metadata service, not generic XSS. Trap two: writing a curl cheat-sheet as if the exam scored command memorization. Identification of the address and the impact (instance role creds) is enough. Trap three: attacking the hypervisor because metadata is 'under the guest.' Metadata is a customer-reachable service on the instance network; it is not a hypervisor exploit.

Session-token flavors of IMDS (often discussed as IMDSv2) are a control you should recognize: requiring a put-token hop makes simple SSRF harder. The exam still wants the attack name when the control is missing.

Exposed storage buckets and directory listing

Exposed storage buckets are object stores — Amazon S3, Azure Blob, Google Cloud Storage, and similar — that list or serve objects to unauthenticated or overly broad principals. Directory listing is the same idea the web chapter used: the container enumerates keys, backups, Terraform state, machine-image exports, or database dumps.

When you pick it: a stem shows a public ACL, public-access block disabled, an anonymous list or get, or a search-engine hit on a bucket hostname. What you do conceptually: demonstrate that an unauthorized principal can list or read (and, if the RoE allows and the ACL permits, write) without becoming root on a VM. Exam trap: calling every public website 'exposed storage.' A CDN front end for a marketing site is not a bucket ACL finding unless the bucket itself is listable or writable. Trap two: treating a public bucket as a provider bug. Under shared responsibility, bucket public access is a customer configuration.

Public access to services, segmentation, and network controls

Public access to services is a security group, network security group, or firewall rule that exposes an admin or data plane to the internet — classically 0.0.0.0/0 (or ::/0) on SSH 22, RDP 3389, database ports, Kubernetes API 6443, or cloud management agents. Network controls and network segmentation fail when every subnet in the VPC can reach every other, when a 'private' database has a public IP, or when a bastion is skipped because the app tier already allows the world.

When you pick it: the stem shows 0.0.0.0/0, a wide-open NSG, a flat VPC, or a managed database with a public endpoint that should have been private. When you do not: a correctly private subnet plus a public load balancer for HTTPS 443 — that is an intended web front door, not 'public access to services' in the admin-port sense. Security groups and equivalent network controls are customer configuration on IaaS. They are not the provider hypervisor.

Logging information exposure

Logging information exposure is secrets and sensitive telemetry landing in logs that the wrong people can read. Pictures the exam likes: access keys or JWTs printed in application logs, connection strings in verbose debug, world-readable log buckets, or CloudTrail-adjacent trails and export buckets whose ACL is public. The log service can be correctly enabled and still be a 4.6 finding if the store is public or if the content is a secret.

When you pick it: the stem shows keys in logs, an open logging bucket, or 'the trail archive is listable.' Exam trap: treating logging exposure as Domain 5 exfiltration. 5.3 is how you sneak data out. 4.6 is the customer's log pile already being readable. Trap two: disabling logging as the 'attack.' Tampering with logging as persistence is closer to 5.1; here the bullet is information exposure.

Third-party integrations: OAuth, CI tokens, SaaS connectors

Third-party integrations extend IAM outside the account. OAuth apps the org approved with broad directory or mailbox scopes, CI tokens (GitHub Actions, GitLab, Jenkins) that can deploy to production, and SaaS connectors that sync the directory or the ticket system with org-wide access are all 4.6 surfaces. The vendor is not automatically in the SoW (1.1 third-party bucket), but the customer's grant to that vendor is customer IAM.

When you pick it: the stem shows a forgotten OAuth app, a CI secret with administrator-equivalent rights, or a marketing SaaS that can read every mailbox. When you do not: attacking the SaaS vendor's own cloud because your customer uses them — that is out of scope unless separately authorized.

Worked cloud account

An in-scope AWS account — customer IAM, not the provider hypervisor — has four facts. A web app on an EC2 instance can be induced, via SSRF, to request 169.254.169.254. That is a metadata service attack that yields the instance role, not a hypervisor exploit and not a curl homework assignment. The same account has an IAM user access key that has not been used in 400 days and a console admin without MFA — IAM misconfiguration and IAM credentials. A role trust allows assume-role from another AWS account the customer does not own — trust relationship abuse. backups-prod lists objects to unauthenticated principals, the SSH security group is 0.0.0.0/0, and the CloudTrail export bucket is world-readable with an access key in a log line — exposed storage, public access to services, and logging information exposure. A forgotten GitHub OAuth app can read every repository — third-party integration. None of these is Pacu-or-bust; tools wait for the next section. Name the attack type first.