ThreatExploit AI
cloud security best practicescloud penetration testingcloud security testing

Cloud Security Best Practices: A Pen Testing Guide

Cloud Security Best Practices: A Pen Testing Guide

An AWS account can pass a broad configuration audit while an attacker still has a viable route to sensitive data. An exposed API may accept a weakly protected request, a service identity may hold permissions it doesn't need, and a permissive trust relationship may let an attacker move into another account. If reachable storage sits at the end of that path, clean audit results offer little comfort.

For a managed security service provider (MSSP), this is a familiar testing problem across AWS, Azure, and Google Cloud Platform (GCP). Cloud penetration testing needs automated breadth to discover assets and flag risky settings, but it also needs manual verification, safe authorization, and evidence that shows what an attacker can do. Configuration findings are leads, not proof of an exploitable path.

These cloud security best practices follow the full penetration-testing lifecycle: authorize the work, discover the attack surface, trace identity and network paths, test storage and modern workloads, assess APIs, and retest changes. Each practice connects a concrete procedure to the evidence that helps a client act on the result. For a broader view of provider trade-offs, see this cloud cost and security breakdown.

Table of Contents

1. Obtain Written Authorization and Follow Cloud Provider Testing Policies

Start with written authorization, not a scanner. The signed scope and rules of engagement should name the accounts and services in scope, approved test methods, testing window, source IP addresses, emergency contacts, and conditions that require testing to stop. Cloud providers operate shared-responsibility models, but customers remain accountable for their own configurations, identities, and data. Provider policies also define where customer testing is permitted and where separate approval or restrictions apply.

AWS allows testing without prior approval against services named in its customer penetration-testing policy, but the policy's permitted scope is specific. It also treats command-and-control activity as requiring prior approval. Don't assume that permission for one service or test type covers every resource in an account.

Make the rules operational

Before testing, record tester source addresses and user agents so the client's security operations center can distinguish authorized activity from an incident. Define a cloud-specific stop condition, such as unexpected service degradation or an alert to a third party, and confirm who can pause the work. Check the provider's current policy at engagement start and retain the version used with the final report.

FedRAMP assessments add formal requirements: classify the service as SaaS, PaaS, and/or IaaS, define systems and constraints in rules of engagement, and obtain Authorizing Official approval before testing. The guidance specifies coverage such as authentication, permissions, sessions, and data access. A reusable cloud penetration testing engagement framework can help standardize those steps across clients.

A useful scope record is precise enough that another tester can tell which account, service, technique, and time window were authorized. If a method could affect a managed service or shared environment, resolve that boundary before execution, not after an alert.

2. Discover the Cloud Attack Surface and Reconcile the Asset Inventory

A cloud inventory is only useful if it matches what an outsider can reach. Begin with passive reconnaissance, including DNS and certificate-transparency data, then enumerate public IP addresses, load balancers, API gateways, storage endpoints, and serverless URLs. Compare the results with a read-only authenticated inventory. The gaps often reveal forgotten test environments, abandoned resources, or shadow IT.

Consider a DNS record that still points to a cloud service the client has released. If an attacker can claim that service, the stale name may become a takeover path. The finding isn't ā€œold DNSā€ alone. It's the relationship between the public hostname, the released resource, and the risk of serving content under a trusted domain.

Reconcile exposure with ownership

Tag each discovered asset with its owner, environment, and business function so the right team can investigate it. Keep evidence of how the asset was reached, but avoid disruptive probing until the scope permits it. At the end of the engagement, repeat discovery and compare the results with the initial inventory; teams may have created new public resources while testing was underway.

For MSSPs, repeatability matters as much as coverage. A consistent process lets testers compare client environments without assuming that identical names or provider labels imply identical exposure. Attack-surface mapping practices can help organize discovery across web, network, and cloud targets.

Automated discovery is fast, but it can produce duplicates, stale records, and assets whose ownership is unclear. Manual reconciliation turns a raw list into a usable attack-surface map, with owners who can confirm whether a resource is expected and whether its exposure is justified.

3. Test IAM Privilege Escalation and Cross-Account Paths

Identity is often the attacker's route from a modest foothold to serious impact. Map users, roles, service accounts, federated identities, and trust relationships, then test what a low-privilege identity can do. Look for wildcard permissions, unused access keys, broad service-account scopes, and role-assumption paths that cross accounts or projects.

A realistic test might begin with a compromised application identity that can assume a deployment role. That role may have permission to pass another role to a service, or to alter a policy that grants access to sensitive resources. The important result is the verified path and its business impact, not a list of isolated permissions.

Prove the path, not just the policy

Use the lowest-privilege test identity available and record each transition with timestamps, relevant policy context, and redacted evidence. Tools such as Pacu and CloudGoat support AWS attack-path exercises; BloodHound and AzureHound help visualize Entra ID and Azure relationships. ROADtools supports research and analysis of Entra ID environments. These tools accelerate investigation, but their output still needs manual validation against the client's actual configuration.

Practical rule: Report a privilege-escalation path only after confirming that the identity can traverse it under the approved test conditions.

Recommend controls that break the demonstrated path, such as narrower trust policies, permission boundaries, service control policies, or conditional access controls. Then retest with the same starting identity. A policy change that looks restrictive on paper isn't a verified fix until the path fails and legitimate workloads still operate.

4. Assess Storage and Data Exposure Without Taking the Data

Object storage findings need careful verification. Check whether buckets, blob containers, or file shares allow anonymous or overly broad access, and whether public-access settings, policy conditions, application logic, or pre-signed URLs expose content. Test direct access and access through the applications or content-delivery layers that serve the data.

A public listing can establish exposure without downloading a dataset. Record the resource, access path, relevant policy, and only the minimal proof needed to show the issue. If a redacted sample is necessary, agree on how it will be handled before collecting it. Don't keep copies of client data as a substitute for evidence.

Keep proof proportionate

The safest finding is one that demonstrates access while minimizing exposure. Provide the client with the affected object names or a controlled inventory and a secure cleanup procedure, rather than retaining sensitive files. This reduces privacy risk and makes it easier for the client to remediate quickly.

Azure testers can use MicroBurst's storage enumeration capabilities as one source of leads, while provider-level public-access blocks and infrastructure-as-code checks help prevent recurrence. Neither replaces manual review of how an application grants access. A storage endpoint may appear private while an application or CDN exposes its contents through a different route.

The report should connect the evidence to the risk: what was reachable, from which identity or network position, and what policy or application behavior allowed it. Avoid overstating impact when the test established exposure but didn't establish access to sensitive content.

5. Test SSRF and Instance Metadata Access

A server-side request forgery (SSRF) flaw can turn an ordinary web request into a route toward internal cloud services. If a workload can reach its instance metadata service (IMDS), an attacker who controls server-side requests may be able to obtain temporary credentials and use them against cloud resources. Test metadata reachability from relevant workload tiers, including containers and CI runners, under the approved scope.

The Capital One breach is a well-known example of the risk: an SSRF flaw in a misconfigured web application firewall was used to reach AWS metadata and obtain role credentials, affecting roughly 100 million customers. The case shows why the testing question isn't whether an application has SSRF. The tester needs to establish whether the flaw reaches metadata, what credentials are exposed, and what those credentials can access.

Verify safely and trace the consequence

AWS introduced IMDSv2 in 2019, requiring session-oriented requests to help mitigate SSRF-based credential theft. Check whether the workload enforces it, whether hop limits are appropriate, and whether the attached role has narrowly scoped permissions. Use canary tokens or non-sensitive test values where possible, and mask credentials in all evidence.

An SSRF test should stop short of using live credentials to access data unless the rules of engagement explicitly permit that validation. Instead, establish the credential exposure safely, then demonstrate the possible impact through policy analysis or an approved controlled test. Recommend egress restrictions for internal address ranges and least-privilege role permissions, then retest with redirects and alternate encodings to catch partial fixes.

6. Verify Network Segmentation and Exposed Services

Cloud networks are policy-defined, so a diagram isn't proof of isolation. Test reachability from multiple vantage points: the public internet, other virtual networks, and connected on-premises environments. Check management ports, production-to-development boundaries, and access to databases or administrative services.

A common scenario is a development subnet reaching a production database through a legacy peering connection. That route may not appear in a perimeter scan, yet it can let an attacker move from a compromised lower-risk environment toward production. Record the source, destination, protocol, and business context of every confirmed path.

Compare intended and observed paths

Use Nmap conservatively to identify reachable services, selecting timing and scope that limit impact on production workloads. Compare observed reachability with infrastructure-as-code definitions to find drift, then draw the confirmed paths so remediation teams can see where segmentation fails. PCI DSS penetration-testing guidance makes segmentation validation especially relevant when defining the scope of a cardholder data environment.

A firewall rule is a claim about reachability. Test from the network position an attacker could actually obtain.

The trade-off is between broad scanning and safe, targeted validation. A wide scan may reveal more services, but it can also generate noise or affect fragile systems. Start with approved targets and measured probes, then expand only when the client has confirmed the operational risk is acceptable.

7. Test Serverless, Containers, and Kubernetes

Ephemeral workloads require testing both the running environment and the pipeline that creates it. Review serverless function permissions, container images, Kubernetes API exposure, role-based access control (RBAC), secrets, and service-account tokens. A function with broad permissions or a pod with an unnecessary token can create an identity path that a perimeter review won't catch.

For example, a compromised web container may inherit a service account that can read secrets or modify deployments. The tester should verify the actual permissions from that workload, not infer risk from a manifest alone. In Kubernetes, check whether API servers are exposed, whether anonymous access is possible, and whether network policies constrain east-west traffic.

Cover build and runtime controls

Test in a staging cluster that mirrors production configuration before probing live workloads. Scan images in the CI pipeline and again at runtime, because the deployed image and its dependencies may change after the build. Check whether service-account tokens are auto-mounted into pods that don't need them, and verify that secrets aren't exposed through environment variables or configuration maps.

Tools such as kube-hunter can help identify exposed Kubernetes components, but a scan doesn't prove that a particular workload identity can reach a sensitive resource. Validate that path within scope, then recommend Pod Security Standards, least-privilege RBAC, network policies, and tighter function permissions where they address the evidence.

8. Assess Cloud-Hosted REST and GraphQL APIs

A cloud API can be protected at the gateway and still fail at the back end. Test authentication, object-level authorization, input handling, rate limits, API key management, and the consistency of controls between gateway and service. For GraphQL, include field-level authorization, introspection exposure, query depth, and batching behavior.

A practical test uses two accounts with the same role. If one account can retrieve or change the other's records by substituting an object identifier, the issue is horizontal authorization failure. Test each endpoint against each relevant role, and compare access through the gateway with any direct route to the back-end service.

Build an endpoint-to-role evidence map

Start from OpenAPI specifications or GraphQL schemas, then verify that the deployed API matches the documented inventory. Use manual requests alongside tools such as Nuclei or SQLMap where appropriate; automated checks can identify patterns, but they can't reliably determine whether business authorization rules are correct. Keep request and response evidence with sensitive values redacted.

The API penetration testing guide can support a repeatable process across REST and GraphQL services. A release pipeline can also run targeted API checks after material changes, but a qualified tester should review high-impact results before they become client findings.

9. Combine Configuration Benchmarks With Manual Validation

Posture tools can check many settings quickly, but a benchmark result is a hypothesis about risk, not proof of exploitability. Use configuration output from tools such as ScoutSuite or Prowler to build a review queue, then manually validate the findings that could create a meaningful attack path. This gives the client both breadth across controls and depth on the weaknesses that matter.

Suppose a scan flags an overly broad role and a public service. Either finding may be low impact alone, but together they may allow an external attacker to reach sensitive data. Group related weaknesses into a chain and show the evidence for each transition. That's more useful than sending separate alerts with no explanation of how they combine.

Make findings comparable and actionable

Map validated issues to applicable controls, such as SOC 2 CC6 criteria or ISO 27001:2022 Annex A controls, when that mapping is relevant to the engagement. Use a consistent severity method, such as CVSS with cloud-specific context, and explain how exposure, privilege, and data sensitivity affect the rating.

NIST's guidance on penetration testing treats it as a structured assessment involving planning, testing, analysis, and mitigation, rather than a scan alone. Its SP 800-115 publication also recognizes that techniques have different benefits and limitations. In practice, combine configuration review, vulnerability scanning, and controlled exploitation, then distinguish verified impact from scanner output in the report.

10. Retest Continuously and Deliver Evidence-Backed Reports

Cloud environments change too often for an annual point-in-time test to stand on its own. Define retest triggers such as a new internet-facing service, an IAM policy change, a new cloud account, or a major API release. PCI DSS v4.0 requires penetration testing at least annually and after significant changes, while ISO 27001:2022 includes security-testing controls. A continuous program helps teams verify changes as they happen, not only when the next audit approaches.

Each report should show what was in scope, how a finding was reproduced, what evidence supports it, who owns remediation, and whether the fix passed retesting. Store tester credentials and API keys in a secrets manager and scope them to the minimum required permissions. For MSSPs, tenant-isolated evidence and role-based access are essential: one customer must not see another customer's reports or test material.

Connect testing to delivery and audit work

Integrate targeted checks into CI/CD so material releases can trigger API and cloud-configuration testing. Don't make every automated alert a production blocker. Reserve blocking decisions for findings with clear severity criteria and reproducible evidence, while routing lower-confidence results for qualified review.

ThreatExploit AI offers automated testing across cloud infrastructure, web applications, and APIs, with evidence-backed reporting, compliance mapping, and CI/CD and API integrations. Review any platform-generated report before delivery to confirm scope, impact, and remediation guidance. For application testing workflows, the app vulnerability scanning guide offers related context.

Cloud Security Best Practices: 10-Point Comparison Guide

Cloud Testing Practice šŸ”„ Implementation Complexity Resource Requirements šŸ“Š Expected Outcomes Ideal Use Cases ā­ Key Advantage
Written authorization and provider-policy review Medium; scope and rules must be documented and kept current Signed scope, provider policy review, contacts, test windows Clear legal boundaries and auditable authorization Every cloud penetration test šŸ’” Reduces contractual risk and accidental impact
Attack surface discovery and asset inventory Mediumā€“High; assets change frequently and require validation Passive and active discovery tools; read-only inventory access Mapped, prioritized view of exposed and unknown assets Reconnaissance and cloud-estate inventory āš” Reveals forgotten or unmanaged resources
IAM privilege-escalation testing High; policy and trust-path analysis needs careful validation Identity metadata access, analysis tools, skilled testers Verified paths from limited access to elevated privileges Assessing identity controls and least privilege šŸ“Š Exposes high-impact attack chains
Storage and data-exposure assessment Lowā€“Medium; access checks are straightforward, data handling needs care Storage inventory, permission checks, minimal evidence capture Identification of public or overly accessible data Reviewing buckets, containers, file shares, and tokens āš” Often provides quick, high-impact findings
Metadata service and SSRF testing High; requires careful testing of application-to-cloud paths Application access, workload context, safe test credentials or canaries Verified risk of credential exposure and cloud-account access Assessing SSRF-prone applications and workload protections ā­ Demonstrates a practical path from web flaws to cloud risk
Network segmentation and exposed-service testing Mediumā€“High; topology and multiple vantage points affect coverage Scanning tools, network diagrams, approved test locations Confirmed reachable services and unintended routes Validating isolation, firewall rules, and PCI DSS segmentation šŸ“Š Tests whether network controls work in practice
Serverless, container, and Kubernetes testing High; workloads are varied and often ephemeral Cluster or workload access, image scanners, staging environments Findings across permissions, secrets, runtime, and configuration Cloud-native workloads and deployment pipelines šŸ’” Covers risks that may be missed by application-only reviews
Cloud-hosted API security testing High; broad endpoint and business-logic coverage takes time API schemas, test accounts, manual and automated tools Verified authentication, authorization, and input-handling flaws REST and GraphQL services, gateways, and back ends ā­ Finds access-control issues scanners may miss
Configuration benchmarking with manual validation Medium; automated checks need contextual review Read-only cloud access, benchmark tools, expert validation Broad control coverage with prioritized, verified findings Baseline reviews and compliance preparation āš” Combines speed and breadth with fewer false positives
Continuous, evidence-backed testing and reporting High; requires repeatable workflows and secure integrations CI/CD integration, scoped credentials, reporting and review processes Faster detection of regressions and audit-ready evidence Frequently changing environments and ongoing compliance šŸ”„ Connects testing to cloud changes and release cycles

Turn the Pentest Program into a Repeatable Cloud Security System

A dependable cloud penetration-testing program runs as an operational sequence, not a collection of unrelated scans. Authorize the engagement, discover the attack surface, validate identity and network paths, test storage and workload exposures, assess cloud-hosted APIs, and retest material changes. Each stage should produce evidence that informs the next one.

Create a repeatable evidence package for every control area. For an identity finding, that might include the starting principal, the permissions used, the role transition, and the resource reached. For an exposed service, record its external entry point, the network path, and the observed response. For storage, keep proof proportionate to the risk and avoid retaining client data. Evidence should be sufficient for a second tester to reproduce the result without relying on undocumented assumptions.

Automated tools provide breadth and consistency, especially across large AWS, Azure, and GCP estates. Qualified manual verification determines whether a setting creates a viable attack path, confirms impact, and prevents scanner output from being presented as a proven compromise. Track remediation ownership, status, and retest results alongside each finding so teams can distinguish an open issue from a fix that has been verified.

Map verified findings to applicable frameworks when compliance reporting is part of the engagement. Keep the technical evidence and the control mapping connected, but don't treat a mapped finding as proof that every requirement has been met. A clear report explains the tested scope, the evidence, the business consequence, the recommended control change, and the retest result.

MSSPs can scale this work without weakening technical quality by standardizing scopes, authorization records, severity criteria, and evidence formats. Tenant-isolated storage and role-based reporting protect client confidentiality, while repeatable procedures help reviewers compare results across engagements. A cloud security guide for managed service providers can provide additional operational context, but the test still needs to reflect each client's actual architecture and risk.

The strongest outcome isn't the longest findings list. It's a verified account of which paths an attacker could use, what breaks those paths, and whether the fix holds after the environment changes. Build that discipline into each engagement, and cloud penetration testing becomes a practical security control as well as a defensible input to client reporting.

ThreatExploit AI supports automated penetration testing across AWS, Azure, and GCP, including reconnaissance, exploitation, verification, and compliance-mapped reporting for service providers. If you're building a repeatable cloud testing workflow, visit ThreatExploit AI to review its capabilities for MSSPs and security consultancies.