Attacks and Exploits · Topic 5 of 10
Cloud-Based Attacks
Learn the cloud attack categories on the PenTest+ exam: container escapes, metadata service abuse and IAM misconfiguration, with indicators and defences.
- 5 min
- The shared responsibility model puts configuration, identity and data protection on the customer.
- Containers share the host kernel, so privileged mode, mounted runtime sockets and host mounts risk escape.
- The metadata service uses the link-local address 169.254.169.254.
What it is
Cloud environments change who controls what. The provider secures the underlying platform, and the customer secures its own configuration, identities and data. This split is called the shared responsibility model.
Many cloud breaches come from the customer side: misconfigured permissions, exposed storage and leaked keys. This page covers three exam categories: container escapes, metadata service attacks and identity and access management (IAM) misconfiguration.
How it works
Testing rules
Before any cloud testing, check the provider's current testing policy, because rules differ and some activities such as denial of service are normally forbidden. The scope must also say whether the customer account, shared services or third-party software as a service (SaaS) tools are in range.
Container escapes
A container packages an application with its dependencies and shares the host kernel. It isolates processes, but it is not as strong a boundary as a virtual machine.
A container escape means breaking out of that isolation to reach the host or other containers. Typical causes are:
| Cause | Why it matters |
|---|---|
| Privileged containers | They have nearly full access to the host |
| Mounted container runtime socket | Control of the runtime means control of the host |
| Host path mounts | Writable access to host files |
| Excess capabilities | Extra kernel rights not needed by the app |
| Kernel or runtime vulnerabilities | Flaws in shared components |
| Weak orchestrator settings | For example, open management interfaces in Kubernetes |
Defences are to avoid privileged mode, run as a non-root user, drop unneeded capabilities, use read-only file systems, apply security profiles such as seccomp and AppArmor, patch the host and runtime, and enforce Kubernetes pod security rules. Image scanning and runtime monitoring catch many problems early.
Indicators include a container process accessing host paths, new privileged pods, or unexpected processes on the host started by a container runtime.
Metadata service attacks
Cloud virtual machines can ask a local metadata service for information about themselves, including temporary credentials for the role attached to the machine. The service listens on a link-local address, 169.254.169.254, on the major providers.
If an attacker can make an application send requests, for example through a server-side request forgery (SSRF) flaw, the application may fetch those credentials for the attacker. The stolen role credentials then work from outside the cloud, within their permissions and lifetime.
Defences:
- Fix SSRF flaws with allow lists and input validation.
- Use the stronger session-based version of the metadata service where the provider offers it, such as version 2 of the Amazon Web Services (AWS) service.
- Give instance roles the minimum permissions.
- Block application access to the metadata address when it is not needed.
- Monitor use of role credentials from unusual addresses.
IAM misconfiguration
IAM controls who can do what to which resource. Weak settings give attackers easy paths.
| Misconfiguration | Risk |
|---|---|
| Wildcard permissions | An identity can do far more than its job requires |
| Overly permissive roles that can be assumed | Lateral movement between accounts or services |
| Permission to change policies or pass roles | Allows privilege escalation within the cloud |
| Long-lived access keys in code or repositories | Anyone who finds them can use them |
| No multifactor authentication (MFA) on privileged users | One stolen password is enough |
| Publicly readable storage buckets | Data exposure without any login |
| Unused accounts and stale keys | Forgotten entry points |
| Trust relationships open to any external account | Others can assume the role |
Cloud testers enumerate which permissions an identity has, then look for ways to combine them into more access. Tools such as ScoutSuite and Prowler audit configurations, and Pacu helps test AWS permissions in an authorised assessment.
Defences are least privilege, regular access reviews, MFA, short-lived credentials, secrets managers, private-by-default storage, and logging through the provider's audit trail with alerts on unusual identity activity.
Other cloud issues
- Exposed management ports and databases open to the internet.
- Insecure serverless functions with broad roles.
- Weak network segmentation between cloud workloads.
- Supply chain risk from third-party images and packages.
- Subdomain takeover when a dangling DNS record points at a deleted cloud resource.
Never use cloud credentials found during a test beyond what the rules of engagement allow, and report exposed keys to the client immediately.
More cloud attack paths
| Path | Idea | Defence |
|---|---|---|
| Third-party integrations | SaaS connectors, OAuth apps and continuous integration links that hold broad tokens | Review granted scopes, remove unused integrations |
| Logging information exposure | Secrets or personal data written to cloud logs that too many identities can read | Keep secrets out of logs, restrict log access |
| Image and artifact tampering | Altering container images or build artifacts in a registry | Image signing, digest pinning, registry access control |
Cloud tools
kube-hunter scans a Kubernetes cluster for weaknesses such as an exposed application programming interface (API) server or kubelet. It complements the configuration auditors named above.
What to remember for the exam
- The shared responsibility model puts configuration, identity and data protection on the customer.
- Containers share the host kernel, so privileged mode, mounted runtime sockets and host mounts risk escape.
- The metadata service uses the link-local address 169.254.169.254.
- SSRF is the usual way to reach the metadata service from a web application.
- Session-based metadata access (such as AWS version 2) and least-privilege roles reduce the risk.
- IAM flaws include wildcard permissions, stale keys, no MFA and public storage.
- ScoutSuite and Prowler audit configuration, and Pacu tests AWS permissions.
- Check the provider's testing policy before any cloud test.
Common mistakes
Assuming the provider secures everything. Customer-side configuration is the common failure.
Treating a container as a virtual machine. Containers share the kernel, so isolation is weaker.
Forgetting the metadata address. A single SSRF flaw can turn into full cloud API access.
Looking only at network ports. Many cloud weaknesses are permission problems that a port scan never shows.
Leaving found keys active. Exposed credentials must be reported and rotated.
Check yourself
What is the metadata service address on major cloud providers?
169.254.169.254, a link-local address.
Why is a privileged container risky?
It has nearly full access to the host, which makes escape easy.
Name two common IAM misconfigurations.
Wildcard permissions and long-lived keys stored in code, or public storage buckets.
Topic 5 of 10 in Attacks and Exploits
Test yourself on Attacks and Exploits
The full CompTIA PenTest+ PT0-003 question bank has 653 questions, with timed practice exams and an explanation for every answer.
This study guide is independent and is not affiliated with, endorsed by, or sponsored by CompTIA. Vendor names, certification names and exam codes are trademarks of their respective owners and are used for identification only.