Cloud Asset Discovery in AWS, GCP, and Azure Environments

Cloud asset discovery maps identities, permissions, and trust relationships rather than IP addresses and open ports, and AWS, Azure, and GCP each concentrate that risk differently. Getting the inventory wrong in any one of the three platforms leaves real attack paths invisible before a test even begins.

Cloud asset discovery versus traditional network reconnaissance

Traditional pentesting starts with a network and works inward: IP ranges, open ports, firewall rules, then whatever services answer on the other side. Cloud reconnaissance maps IAM roles, API control planes, trust relationships, and resources that may only exist for a few minutes before they disappear.

The shared responsibility model is part of why. A cloud customer only controls, and only gets to test, what they configure on top of the provider's infrastructure, leaving the data centers and hypervisors underneath outside that scope. That limits scope in a way traditional network testing never had to account for.

Ephemeral infrastructure makes the problem sharper. An EC2 instance scanned today can be terminated by tomorrow, but the IAM role attached to that instance often persists well past the compute it was built for, carrying whatever permissions it was given, over-permissioned or not. A scan that only catalogs running instances misses the identity artifacts that outlive them, and those artifacts are usually where the real risk sits.

That shift is structural. Cloud environments invert the assumptions traditional testing was built on: there's no single perimeter to map, because the boundaries that matter are logical isolation between accounts, IAM permission chains, and API control planes. Much of the infrastructure being tested doesn't even have an operating system to log into. Serverless functions, managed databases, and container orchestration layers replace the host a tester would normally SSH into, so discovery has to run through API calls and policy inspection instead of port sweeps.

Visibility works differently too. Every major cloud platform logs activity by default, through CloudTrail, Azure Activity Log, or GCP Cloud Audit Logs, which changes what a tester is actually trying to prove. The activity is already being recorded, so the test measures whether the organization's detection systems catch it. Cloud recon rewards validating that someone would notice.

All of this points at the same conclusion: identity is the perimeter in cloud environments.

A complete cloud asset inventory across all three platforms

A cloud asset inventory has to cover compute, storage, databases, network configuration, IAM, and infrastructure-as-code artifacts before anyone can reason seriously about attack paths. If a category is skipped, the resulting attack surface map is not just smaller; it's wrong in ways that don't announce themselves.

Compute includes virtual machines (EC2, Azure VMs, GCP Compute Engine instances), functions-as-a-service (Lambda, Azure Functions, Cloud Run), and container clusters (EKS, AKS, GKE). Databases, DynamoDB, Azure SQL, GCP Cloud SQL, and other managed database services, matter less for what host they run on and more for what access policy governs them and whether they're publicly exposed.

Network components round out the infrastructure side: VPCs, security groups, subnets, load balancers, and API gateways all define what can reach what. IAM entities, users, roles, service accounts, and the policies attached to them, are where the highest-impact findings concentrate across all three providers. That single category deserves more attention in an inventory than any other, because a single overly permissive role or service account can undo the protection every other control provides.

Infrastructure-as-code artifacts belong in the inventory too, even though they aren't running services. Terraform templates, CloudFormation stacks, and CI/CD pipeline configurations shape what gets deployed, and a flaw baked into a template reproduces itself every time that template runs. One cloud pentesting guide lists the required catalog explicitly: EC2 instances, Lambda functions, S3 buckets, EBS volumes, RDS, DynamoDB, VPCs, security groups, and IAM entities, all inventoried before any configuration review begins.

Logging coverage is part of the inventory. CloudTrail, CloudWatch, Azure Monitor, and GCP Cloud Audit Logs need to capture events from ephemeral workloads and serverless triggers just as reliably as they capture events from persistent virtual machines. A gap in logging coverage for short-lived resources means an entire class of activity leaves no record, and that absence becomes visible only after it matters.

AWS asset discovery and its IAM attack paths

Role-chaining and wildcard policies create privilege escalation paths that configuration review alone cannot expose.

Discovery typically starts with the AWS CLI under read-only credentials. aws ec2 describe-instances enumerates EC2 instances, aws s3 ls lists S3 buckets, and aws iam get-account-authorization-details pulls the full set of IAM policies and roles for later analysis. That enumeration needs to run across every region a given AWS account uses, not just the default one, because resources outside the primary region get overlooked routinely and misconfigured just as often.

Storage exposure is still a recurring finding. A meaningful share of S3 buckets remained publicly accessible as of 2024, and tools like S3Scanner check for public read or write access at scale. Security groups need direct review for any rule permitting inbound traffic from any source, because open ports in security groups appear consistently across AWS engagements.

IAM is where the actual damage concentrates. The single most common and highest-impact finding in AWS environments is the overly permissive role, often built on wildcard *:* policies that grant unrestricted access across every service and action in the account. Mapping what those roles actually allow requires a different kind of tool than a configuration scanner. PMapper builds IAM privilege-escalation graphs, showing which identities can reach which other identities through role-chaining, similar in function to BloodHound for Active Directory. A finding from a tool like that proves lateral movement is possible.

Pacu takes the next step, functioning as the primary AWS offensive exploitation framework capable of enumerating, pivoting, and demonstrating real impact. Because it can modify resources and expose sensitive data in the process, it needs tighter authorization controls than any read-only tool. Native AWS services provide a useful baseline alongside these: AWS Inspector automatically discovers EC2 instances and Lambda functions and reports findings into AWS Security Hub, though it's a signal source rather than a replacement for manual privilege-escalation analysis. CloudMapper adds a visual layer, generating network diagrams that make trust relationships between accounts and overall network topology visible at a glance.

The clearest illustration of how AWS discovery and exploitation connect, rather than sit as separate stages, is server-side request forgery against the EC2 metadata service. A successful SSRF against 169.254.169.254 can steal IAM credentials directly, and those credentials can open the door to privilege escalation through iam:PassRole, cross-account role assumption, and exfiltration of data from an entirely different AWS account. A single web application vulnerability, followed all the way through, becomes a full kill chain.

Any of this work needs to stay inside AWS's own rules. AWS permits customers to test their own infrastructure across listed services without prior approval, but testing AWS's underlying infrastructure itself is off limits, and command-and-control activity requires approval in advance. Check the current AWS customer penetration testing policy before any engagement starts, since those terms change.

Azure asset discovery and its identity federation risks

Azure's identity-as-perimeter risk runs through managed identities and federated single sign-on, which create trust relationships that cross organizational and subscription boundaries.

Microsoft Defender for Cloud (formerly Azure Security Center) offers continuous assessment of Azure resources, and it's a reasonable baseline inventory signal, though it doesn't substitute for manually tracing trust relationships. A full enumeration covers Azure VMs, Azure Functions, Blob Storage containers, Azure SQL databases, Azure Kubernetes Service clusters, virtual networks, network security groups, and the full set of Microsoft Entra ID objects, users, groups, service principals, and managed identities.

Managed identities function as Azure's answer to the AWS IAM role attached to compute. A compromised VM or Function carrying a managed identity can call Azure Resource Manager APIs with whatever permissions that identity holds, and it does this without any credential ever being stored anywhere an attacker could find it sitting still. That's part of what makes managed identity exploitation a genuinely distinct attack vector, one that didn't exist in this form five years ago.

Federation creates exploitable trust boundaries, as OAuth and OpenID Connect flows cross organizational lines by design, and single sign-on integrations mean a misconfigured trust relationship in one tenant can become an entry point into a completely different tenant. Service principal permissions and app registrations inside Entra ID need explicit, direct enumeration for this reason. Over-permissioned app registrations appear consistently in Azure environments, and configuration review alone tends to miss them.

ScoutSuite covers Azure alongside its other supported platforms, producing a consolidated misconfiguration report across IAM, storage, networking, and compute, which gives useful breadth across multiple subscriptions at once.

Microsoft's rules for testing are more prescriptive than either of the other two providers. Denial of service, excessive automated traffic, and post-compromise actions such as dumping secrets, enumerating internal networks, lateral movement, and pivoting beyond initial identification are all prohibited, along with any access to data or systems outside the assets actually authorized for testing. Testing is permitted under Microsoft's Cloud Unified Penetration Testing Rules of Engagement, but shared-tenant testing and anything resembling denial-of-service stays restricted, and that document needs a direct read before selecting which Azure techniques to run.

GCP asset discovery and service account risk

GCP's asset discovery work centers on one object more than any other: the service account. GCP's service account architecture concentrates credential risk in a way that differs from both AWS IAM roles and Azure's managed identities.

A full enumeration covers Compute Engine instances, Cloud Functions, Cloud Run services, GKE clusters, Cloud Storage buckets, Cloud SQL instances, BigQuery datasets, IAM service accounts and their bindings, and VPC firewall rules. Service accounts sit at the center of that list because they aren't just identities, they're resources in their own right. A service account can be granted roles, impersonated by other service accounts, and given a downloadable JSON key file, and that key file is where a large share of the real risk lives. Developers routinely store these files in source repositories, container images, and environment variables, which turns key leakage into a top finding across GCP engagements. GCP service account key leakage is named as its own distinct attack vector specific to the platform.

Impersonation chains are GCP's version of AWS role-chaining: one service account permitted to impersonate another with broader permissions, effectively inheriting that account's access. Mapping those chains is the single highest-value piece of analysis in a GCP IAM review. Google Cloud Security Command Center helps centralize the findings that come out of that kind of review, surfacing misconfigured storage buckets, overly permissive service accounts, and public-facing resources across every project in an organization.

GKE clusters add a second layer to check. Enumeration needs to cover the Kubernetes RBAC layer and the underlying GCP IAM layer separately, because a misconfiguration at either layer can let a compromised container workload escalate straight into the GCP control plane. That escalation path, from a container workload up through Kubernetes RBAC into the cloud provider's own IAM system, is a reminder that container orchestration and cloud identity are no longer separate problems to solve one at a time.

Google's own testing rules are comparatively permissive. Advance notice isn't required to test a customer's own project, as long as the test complies with the Acceptable Use Policy and Terms of Service and stays contained to that customer's own projects. The current position in the Google Cloud security FAQ is worth confirming directly before relying on that, since provider policies shift.

Tools that work across all three platforms

Building a tool stack for multi-cloud discovery means separating four distinct jobs: posture assessment, attack-path modeling, adversary emulation, and workload scanning. Treating these as interchangeable, or covering one and assuming it stands in for the others, produces gaps in coverage and false confidence in the results.

Posture assessment is the breadth layer, configuration review across as much of the environment as possible. Prowler is the strongest starting point here, with active maintenance and checks spanning AWS, Azure, GCP, Kubernetes, GitHub, Microsoft 365, and more, making it the most complete open-source framework in this category. ScoutSuite covers the same ground with a consolidated HTML report across AWS, Azure, and GCP, plus Alibaba Cloud and Oracle Cloud Infrastructure.

Attack-path modeling answers a question configuration scanners can't touch: what can an attacker actually reach from a given starting identity? PMapper maps IAM privilege-escalation graphs in AWS, and CloudFox discovers attack paths across cloud environments, together answering what an attacker can reach from a given starting identity, a question configuration scanners cannot answer. A clean configuration scan and a clear attack path are different findings, and an engagement that only produces the first is missing the analysis that tells an organization what actually happens if one account gets compromised.

Adversary emulation moves from mapping to testing whether detection actually works. Stratus Red Team runs controlled actions that simulate real attacker techniques and checks whether an organization's detection controls fire in response. Pacu is the AWS-specific offensive framework for demonstrating exploitability, and because it can change resources and expose sensitive data, it needs tighter authorization controls and ideally a representative non-production environment to run in.

Workload and container scanning covers a layer the cloud control-plane tools never reach. Trivy and Kubescape scan container images and Kubernetes configurations, while kube-bench checks Kubernetes cluster configuration specifically against CIS Benchmark standards. None of these replace cloud asset discovery, they complement it, operating one layer down from the account and identity structure the rest of this stack is built to map.

Choosing among all of this comes down to answering a short set of practical questions before picking a tool: what risk question is actually being answered, which platforms are in scope, whether the goal is breadth or depth, and whether the engagement calls for read-only analysis or controlled exploitation. AWS, Azure, and GCP each concentrate their identity risk differently, in IAM role-chaining, managed identity and federation, and service account impersonation respectively.