iwantcoding.com
🔥 Daily 👥 Rooms 🏆 Top Log in Sign up

Cloud Pentesting Basics

By · Reviewed & last updated · Part of Ethical Hacking Tutorial

Defensive view: cloud security. Authorised engagements only. The focus is what defenders should harden and detect in AWS, Azure, GCP.

Defender-first overview

EXAMPLE
# Cloud security - defender perspective

> Lab and authorised engagements only. This page describes cloud misconfig
> patterns so defenders can build controls and detection. Live cloud
> engagements require signed Rules of Engagement (RoE) and scoped consent;
> testing against unauthorised accounts is illegal in most jurisdictions.

## High-impact misconfigs defenders should hunt

- IAM roles with NotAction or wildcard Resource (effective admin)
- Public S3 buckets or storage accounts (BucketOwnerEnforced not set)
- IMDSv1 still allowed on EC2 (SSRF + steal role)
- Cross-account roles with no external ID
- Long-lived access keys for IAM users
- Public RDS / databases reachable from 0.0.0.0/0
- Lambda functions with broad EC2/S3 permissions
- KMS keys without grants policy controls

## Controls that move the needle

- SCPs (Service Control Policies) deny risky regions / services org-wide
- IAM Access Analyzer reviews + auto-tickets
- BucketOwnerEnforced + Block Public Access on every account
- IMDSv2 required (token-based) - phased rollout, then enforce
- OIDC federation from CI - no static keys
- AWS Config or equivalent (Azure Policy, GCP SCC) with auto-remediation
- VPC endpoints for S3, DynamoDB, Secrets Manager - keep traffic private
- Secrets in Secrets Manager / KeyVault / Secret Manager - never env vars

## Detection signals

- CloudTrail: ConsoleLogin from new IPs, role chaining anomalies
- GuardDuty findings (or Defender for Cloud, SCC)
- New IAM user or access key creation
- New cross-account assume-role from unknown principals
- Public-access toggle on a storage bucket
- Lambda environment variable updates writing secrets
- Disabled CloudTrail / log delivery destination changes

## Engagement reporting

- Map each finding to a control (SCP, IAM policy, Config rule)
- Prefer 'fix the policy template' over 'fix this account' for repeat misconfigs
- Quick wins: BucketOwnerEnforced, IMDSv2, leaked-key rotation
- Long programmes: workload identity federation, SCP-led blast radius limits

## Tools (defensive)

- Prowler, ScoutSuite, CloudSploit - benchmarks against CIS / FedRAMP
- Cartography, Steampipe - graph + SQL the cloud control plane
- IAM Access Analyzer + CloudTrail Lake for forensic queries
- aws-vault for short-lived MFA-backed creds in ops

Why it matters

Cloud security is mostly identity, network, and logging. SCPs + OIDC + Block Public Access + Config rules close most doors. Treat findings as policy template fixes, not one-off account fixes - that is the only scalable defence.

Tip: Tweak the snippet with Try it Yourself », then sit the quiz at the bottom of the page.

Example

Example
# Cloud pentest highlights:
#   - Public buckets / blobs (S3, GCS, Azure Blob)
#   - Over-permissive IAM roles
#   - Exposed metadata (IMDSv1)
#   - Misconfigured KMS, CloudTrail off
# Tools (with permission): ScoutSuite, Prowler, pacu, kube-hunter for K8s.
Try it Yourself »

Discussion

Loading…