performing-cloud-penetration-testing

Performs authorized penetration testing of cloud environments across AWS, Azure, and GCP to identify IAM misconfigurations, exposed storage buckets, overly permissive security groups, serverless function vulnerabilities, and cloud-specific attack paths from initial access to account compromise. The tester uses cloud-native tools and specialized frameworks like Pacu and ScoutSuite to enumerate and exploit cloud infrastructure. Activates for requests involving cloud pentest, AWS security assessment, Azure penetration testing, or cloud infrastructure security testing.

Ir para a instalação

Repositório: autohandai/community-skills
Última atividade na origem: 16 de março de 2026 às 00:59
Idioma detectado do SKILL.md: inglês
Estrelas: 10
Forks: 3

Opções de instalação

Por padrão, está selecionado o prompt que primeiro revisa a origem. Você pode mudar para um comando direto ou baixar uma cópia local.

Revise os arquivos de origem

Leia o SKILL.md e os arquivos complementares exibidos pelo SkillsMP antes de decidir se vai instalar.

Voltar à pesquisa Voltar à instalação

name	performing-cloud-penetration-testing
description	Performs authorized penetration testing of cloud environments across AWS, Azure, and GCP to identify IAM misconfigurations, exposed storage buckets, overly permissive security groups, serverless function vulnerabilities, and cloud-specific attack paths from initial access to account compromise. The tester uses cloud-native tools and specialized frameworks like Pacu and ScoutSuite to enumerate and exploit cloud infrastructure. Activates for requests involving cloud pentest, AWS security assessment, Azure penetration testing, or cloud infrastructure security testing.
domain	cybersecurity
subdomain	penetration-testing
tags	["cloud-pentest","AWS-security","Azure-security","IAM-exploitation","cloud-infrastructure"]
version	1.0.0
author	mahipal
license	Apache-2.0

Performing Cloud Penetration Testing

When to Use

Assessing the security posture of cloud infrastructure before or after migration from on-premises
Testing IAM policies, security groups, and network ACLs for overly permissive configurations
Evaluating the security of serverless architectures (Lambda, Azure Functions, Cloud Functions)
Identifying exposed cloud storage (S3 buckets, Azure Blob containers, GCS buckets) containing sensitive data
Testing the effectiveness of cloud security controls (GuardDuty, Defender for Cloud, Security Command Center)

Do not use without both written authorization from the cloud account owner AND compliance with the cloud provider's penetration testing policy (AWS requires no prior approval for most services; Azure and GCP require notification or approval for certain test types).

Prerequisites

Written authorization specifying target cloud accounts, regions, and services in scope
Compliance with cloud provider penetration testing policies (AWS Penetration Testing Policy, Azure Penetration Testing Rules, GCP Acceptable Use Policy)
Cloud credentials at various privilege levels (read-only, developer, admin) for testing authorization boundaries
Pacu (AWS), PowerZure (Azure), or GCP-specific exploitation frameworks installed
ScoutSuite or Prowler for automated cloud security posture assessment
AWS CLI, Azure CLI, and/or gcloud CLI configured with test credentials

Workflow

Step 1: Cloud Reconnaissance and Enumeration

Enumerate the cloud environment to map the attack surface:

AWS Enumeration:

aws sts get-caller-identity - Verify current identity and account
aws iam list-users - List all IAM users
aws iam list-roles - List all IAM roles and their trust policies
aws s3 ls - List all S3 buckets
aws ec2 describe-instances --region us-east-1 - List EC2 instances
aws lambda list-functions - List Lambda functions
aws rds describe-db-instances - List RDS databases
Use Pacu for automated enumeration: run iam__enum_permissions, run iam__enum_users_roles_policies_groups

Azure Enumeration:

az account list - List subscriptions
az ad user list - List Azure AD users

Term	Definition
IAM Privilege Escalation	Exploiting overly permissive IAM policies to elevate from limited access to administrative control over the cloud account
Instance Metadata Service (IMDS)	An HTTP endpoint (169.254.169.254) on cloud instances that provides instance configuration and IAM role credentials, exploitable via SSRF
Assumed Role	An IAM role that a user or service temporarily assumes to gain its permissions, governed by trust policies that define who can assume the role
SCPs (Service Control Policies)	Organization-level policies in AWS Organizations that set permission boundaries for accounts, overriding IAM policies
Managed Identity	Azure's equivalent of AWS IAM roles for services, providing automatic credential management for Azure resources
Resource Policy	Access control policy attached to a cloud resource (S3 bucket, Lambda function, SQS queue) that defines cross-account and public access

## Finding: Cross-Account Role Trust Allows Development-to-Production Pivot

**ID**: CLOUD-002
**Severity**: Critical (CVSS 9.6)
**Cloud Provider**: AWS
**Affected Account**: Production (111222333444)
**Exploited From**: Development (555666777888)

**Description**:
The production account IAM role "ProdDataAccess" has a trust policy that allows
the Lambda execution role "LambdaDevRole" in the development account to assume
it. This cross-account trust, combined with the developer's ability to modify
Lambda function code, creates a path from development read-only access to
production data access.

**Attack Chain**:
1. Enumerate Lambda functions in dev: aws lambda list-functions
2. Identify LambdaDevRole has sts:AssumeRole permission
3. Modify Lambda to assume ProdDataAccess: aws sts assume-role --role-arn arn:aws:iam::111222333444:role/ProdDataAccess
4. From assumed role: aws s3 ls s3://prod-customer-data -> 2.3 million customer records

**Impact**:
An attacker compromising any developer credential can access production
customer data (2.3 million records) without directly attacking the production
account.

**Remediation**:
1. Restrict the ProdDataAccess trust policy to specific production roles only
2. Remove sts:AssumeRole from the LambdaDevRole policy
3. Implement AWS Organizations SCPs to prevent cross-account role assumption from development
4. Enable CloudTrail alerts for cross-account AssumeRole events
5. Encrypt S3 bucket with KMS key that the development account cannot access