Cloud Penetration Testing Report — Sample

A Cloud Penetration Testing engagement is an authorized, hands-on security assessment that combines external black-box reconnaissance, authenticated cloud configuration review, limited-privilege IAM testing, and assumed-breach/compromised-workload testing to identify exploitable weaknesses across a cloud environment's identity, storage, network, workload, and logging layers. This illustrative sample shows how TMG Security structures that deliverable for an AWS-primary environment spanning multiple accounts.

This sample report demonstrates TMG Security's approach for a fictional organization, AstraVault Technologies, Inc., a FinTech / enterprise SaaS company providing a cloud-based financial workflow and analytics platform on Amazon Web Services (AWS). TMG Security did not have, and does not claim to have had, unrestricted AWS Management Console access at any point in this fictional engagement — testing was conducted from four defined assessment perspectives: external black-box, authenticated cloud configuration review, limited-privilege IAM assessment, and assumed-breach / compromised-workload.

This sample cloud penetration testing report is a fictional, illustrative deliverable prepared for an AWS cloud security assessment — not to describe any real organization's security posture.

None of these samples is a certification, an attestation, an actual client engagement, or proof of any compliance or security status. This report is labeled as illustrative throughout and carries a full disclaimer on this page and within the sample PDF.

AstraVault's fictional AWS environment is organized under a single AWS Organization spanning three accounts: AstraVault Production, which hosts primary production workloads, the customer-facing API, and transactional data; AstraVault Security, which centralizes logging, CloudTrail/GuardDuty/Security Hub aggregation, and break-glass administrative access; and AstraVault Development, the engineering development and staging/CI-build environment. The architecture follows a public-facing content-delivery and web path (Route 53 → CloudFront → AWS WAF → Application Load Balancer → ECS/EC2 application workloads → RDS), a parallel API/event-driven path (API Gateway → Lambda → SQS/EventBridge → processing workloads), and a security-services layer (CloudTrail, CloudWatch, GuardDuty, Security Hub, KMS, Secrets Manager) spanning both.

Testing was conducted over the fictional window of 07 September 2026 – 25 September 2026 (13 business days), from four assessment perspectives: external black-box; authenticated cloud configuration review (read-only, cross-account audit-scoped role); limited-privilege IAM assessment (standard low-privilege application/engineering-tier identity); and assumed-breach/compromised-workload (simulating a workload already compromised via SSRF or a vulnerable container, without performing the initial compromise technique against a real system). No destructive testing, denial-of-service testing, or resource deletion of any kind was performed. Critical findings were communicated to the fictional AstraVault security team within 24 hours of confirmation.

TMG Security's fictional cloud penetration testing methodology combined external unauthenticated reconnaissance of AstraVault's internet-facing AWS surface, authenticated configuration review across all three fictional accounts using a read-only cross-account audit role, limited-privilege IAM testing to validate documented privilege-escalation and cross-account trust techniques, and assumed-breach testing to assess blast radius from a simulated compromised workload. Each finding is assigned an illustrative CVSS v3.1-inspired base score and a qualitative severity rating (Critical, High, Medium, Low, Informational); these are TMG Security's own sample estimations for this fictional exercise and are not submitted to any CVSS numbering authority.

TMG Security’s fictional AWS Cloud Penetration Testing methodology and severity-rating approach are informed by, but not certified against, the AWS Well-Architected Framework Security Pillar, combined with hands-on testing specific to the target’s multi-account IAM and workload architecture.

TMG Security is not affiliated with, endorsed by, reviewed by, or certified by AWS, PTES, NIST, OWASP, or any other standards organization unless explicitly stated otherwise. Nothing in this report implies AWS certification, partnership, or endorsement of TMG Security or of this assessment.

TMG Security enumerated assumable roles reachable from a fictional low-privilege AstraVault Production IAM user and tested documented AWS IAM privilege-escalation patterns, including cross-account trust relationships and IAM policy-chaining techniques.

TMG Security enumerated all fictional production S3 buckets for public accessibility, encryption enforcement, versioning, and access logging, and reviewed bucket resource policies for unnecessary cross-account grants.

TMG Security tested EC2 instance-metadata-service configuration for IMDSv1 exposure and tested whether an internet-facing application feature could be converted into server-side credential theft via SSRF.

TMG Security reviewed AstraVault's four-tier subnet model (public, private-application, private-database, and management) for correct isolation, and reviewed security-group rules for unnecessary administrative-port exposure.

TMG Security reviewed Lambda execution-role permissions against each function's actual requirements, and reviewed API Gateway endpoints for missing request validation.

TMG Security scanned production container images in ECR for known-vulnerable packages and reviewed ECS task definitions for excessive Linux capabilities.

TMG Security tested network-layer reachability of RDS instances, reviewed how database credentials are supplied to workloads, and reviewed KMS key policies for overly broad decrypt permissions.

TMG Security reviewed CloudTrail data-event coverage, CloudWatch alerting on high-risk IAM and security events, and whether GuardDuty and Security Hub findings route to a centralized alerting channel across all three fictional accounts.

TMG Security reviewed AWS WAF rule coverage on public-facing endpoints and reviewed CloudFront's security-header enforcement.

TMG Security reviewed the trust relationships between AstraVault's three accounts, reviewed AWS Backup configuration for production database resources, and reviewed the CI/CD pipeline's handling of deployment credentials.

This fictional assessment identified 42 illustrative findings across AstraVault Technologies, Inc.'s AWS cloud environment, drawn from 138 fictional test cases. Every finding, severity rating, and evidence reference below is fictional and specific to this Cloud Penetration Testing engagement.

Individual findings, viewed in isolation, can understate real-world cloud risk. TMG Security chained this report's findings into four realistic, fictional, non-destructive composite scenarios and validated the technical feasibility of each step in a controlled manner — no chain was executed end-to-end against a live system, and no destructive or state-changing action was taken at any point.

Step 1: An unauthenticated attacker discovers the internet-facing report-fetch feature on api.astravault-example.com during external reconnaissance. Step 2: The attacker supplies a link-local metadata URL as the export destination; the feature performs no destination validation, and the backing EC2 fleet permits legacy IMDSv1 with no session-token requirement (CLOUD-003). Step 3: The attacker recovers live, temporary IAM credentials for the astravault-ec2-app-role instance profile directly from the metadata response. Step 4: That role's permissions — broader than the workload's actual function requires, echoing the over-permission pattern in CLOUD-001 — allow read access to the publicly-adjacent astravault-prod-financial-statements S3 bucket (CLOUD-002), which was already independently confirmed reachable by any unauthenticated user.

Business impact: This chain demonstrates that AstraVault's most severe fictional exposure requires no insider access and no social engineering — only a single unauthenticated application-layer weakness, converted into cloud credential theft and sensitive financial-data access through two further, independently-documented misconfigurations.

Step 1: An attacker compromises a fictional Development-account developer credential — the more attainable target given the Development account's weaker baseline controls (CLOUD-041). Step 2: The attacker assumes the astravault-prod-devsupport-role using the overly broad Production-to-Development cross-account trust relationship, which requires no MFA or ExternalId (CLOUD-005). Step 3: Using the assumed role's read access, the attacker retrieves the financial-database credential from Secrets Manager — correctly stored, but not rotated on a defined schedule (CLOUD-032). Step 4: The attacker uses the recovered credential to connect to the astravault-analytics-reporting-db instance, which is independently reachable at the network layer from the internet (CLOUD-010).

Business impact: This chain shows how a gap in account segmentation allows a foothold in AstraVault's lowest-assurance environment to reach production database credentials and a network-exposed database instance, entirely bypassing the isolation the account structure is intended to provide.

Step 1: An attacker exploits the known-vulnerable base-image package in the currently-deployed astravault/analytics-worker container image, which the CI/CD pipeline did not block despite an available Critical-severity scan finding (CLOUD-008). Step 2: The container's elevated Linux capabilities (SYS_ADMIN, NET_ADMIN), broader than its documented functional need, increase the feasibility of moving from application-level code execution toward the container boundary (CLOUD-024). Step 3: The attacker retrieves the ECS task role's temporary credentials via the in-container task metadata endpoint. Step 4: Because Lambda/task execution roles in AstraVault's environment follow a broadly-shared, over-permissioned pattern (CLOUD-009), the attacker uses the recovered credentials to modify cloud resources (e.g., S3 objects, DynamoDB records) beyond the compromised service's legitimate function.

Business impact: This chain illustrates how a single unpatched container dependency, combined with excess container privilege and over-permissioned execution roles, escalates from application-level compromise to unauthorized cloud-resource modification — all three contributing weaknesses independently remediable.

Step 1: An attacker compromises a standard fictional engineering-tier credential (e.g., via phishing) — a much lower bar than compromising an already-privileged identity. Step 2: Using the astravault-platform-engineers group's iam:CreatePolicyVersion and iam:PassRole permissions, the attacker creates a new policy version granting broader access and passes an elevated role to a newly created Lambda function — a documented IAM privilege-escalation pattern (CLOUD-004). Step 3: The attacker executes arbitrary AWS API calls under the elevated role's identity, including further AssumeRole calls. Step 4: This reaches the same overly broad cross-account trust path documented in Attack Chain 1 and CLOUD-001, achieving full fictional Security-account compromise from a starting point that required no privileged access at all.

Business impact: This chain demonstrates that AstraVault's most critical exposure (CLOUD-001) is reachable not only by directly compromising a highly-privileged identity, but via a documented, automatable technique from a standard engineering credential — meaningfully widening the realistic population of attack starting points.

This section translates the technical findings above into fictional business terms for AstraVault's executive and board-level audiences, framed around the specific risks a FinTech / enterprise SaaS platform faces from cloud misconfiguration.

The fictional remediation roadmap below phases all 42 findings into four windows aligned to severity and technical dependency, so AstraVault's engineering teams can sequence work efficiently — addressing the findings that unlock the Section 17 attack chains first.

Consistent with TMG Security's standard reporting practice, this section documents fictional controls confirmed operating effectively during this assessment — an important counterweight to the findings sections, since a cloud security report that only lists problems gives an incomplete picture of AstraVault's actual fictional posture. Confirmed positive controls include: the primary transactional RDS Aurora cluster correctly placed in a private database subnet with scoped security-group access; the organization CloudTrail correctly multi-region with log-file validation and a tamper-resistant delivery-bucket policy; 21 of 22 fictional production S3 buckets correctly enforcing Block Public Access, and 16 of 22 correctly enforcing default SSE-KMS encryption; an OIDC/workload-identity-federated CI/CD deployment pipeline with no hard-coded static secrets found in build configuration; GuardDuty and Security Hub enabled organization-wide with centralized delegated-administrator visibility; a four-tier network-segmentation model correctly implemented for the vast majority of Production resources; several documented IAM privilege-escalation patterns correctly blocked by existing permission boundaries; encryption at rest confirmed enabled fleet-wide for EBS volumes and all reviewed database resources; a correctly-scoped break-glass administrative role with hardware MFA and approval logging; and broken object-level authorization testing against account-data and funds-transfer endpoints finding no exploitable authorization bypass. These positive observations do not offset the findings elsewhere in this report; they are provided for a complete and balanced picture of AstraVault's fictional security posture.

As with any time-boxed security assessment, this fictional engagement is subject to inherent limitations. This assessment reflects AstraVault's fictional AWS environment configuration as observed during the 07–25 September 2026 assessment window; any configuration change made after that window is not reflected in this report. Testing was performed from the four assessment perspectives defined in Section 04; TMG Security did not have unrestricted AWS Management Console access and cannot claim complete visibility into every possible misconfiguration an administrator-level review might surface. No destructive or denial-of-service testing was performed; some classes of availability-impacting weakness may not have been fully validated. Source-code-level application security testing was out of scope for this cloud-infrastructure-focused engagement; application-layer vulnerabilities not visible at the cloud-configuration layer may exist and are better addressed by TMG Security's companion Web Application and API assessment services. Third-party vendor infrastructure (e.g., the fictional payment aggregator) was not tested directly; only AstraVault-side integration configuration was reviewed. This report represents a point-in-time assessment; cloud environments change continuously, and TMG Security recommends recurring assessments (at minimum annually, or after significant architecture changes) to maintain an accurate risk picture.

Looking to validate your own AWS environment's security directly? TMG Security's Cloud Security Testing team can scope a real Cloud Penetration Testing engagement built with the same structure, methodology, and reporting depth shown in this sample — IAM and privilege-escalation testing, S3 and workload security, network segmentation review, and a full sample findings report.