Cloud

Cloud tooling divides cleanly along one line: before a credential and after one. Before, you are reading posture from the outside or from a read-only role — orientation, not exploitation. After, you are enumerating what a specific principal can do and chaining it into more. Confusing the two produces the classic beginner report: a wall of posture findings with no demonstrated impact.

Authorized targets only

Provider rules of engagement are their own layer on top of the client’s. Some tests require advance notice to the provider; some techniques are prohibited outright. Confirm both before you start.

Posture assessment: before the foothold

scout suite <provider>: multi-cloud posture assessment. Output: an HTML report of misconfigurations against a benchmark, across AWS, Azure and GCP. Next: orientation and a shortlist of weak spots. This is posture, not exploitation — every finding is a candidate to be confirmed, not a result to be reported.

prowler aws (also prowler azure, prowler gcp): checks against CIS and other benchmarks. Output: pass/fail per check, mapped to the benchmark control. Next: the compliance-flavoured view — useful when the engagement has a framework in scope, and a good cross-reference against ScoutSuite since they disagree at the edges.

cloudsplaining --input policy.json: risk analysis of an IAM policy document. Output: the policy’s privilege-escalation and resource-exposure risks, called out. Next: reads a policy for danger without touching the account — the static counterpart to the enumeration below, and the same question a least-privilege review asks from the defensive side.

AWS: after the foothold

pacu: AWS exploitation framework. Output: enumeration and privilege-escalation modules run against a credential. Next: where an AWS engagement lives once you hold a key. Enumerate permissions first (iam__enum_permissions), then test the escalation chains the permissions allow — iam:PassRole to a more privileged role is the canonical one.

aws sts get-caller-identity: confirm whose credentials you hold. Output: the account, principal and ARN of the current credential. Next: the first command after acquiring any AWS credential — it tells you which identity you have before you spend effort finding out the hard way. From here the metadata service (169.254.169.254, IMDSv2) on a compromised instance is the classic route to a role credential.

Azure and Entra: after the foothold

roadrecon: Entra ID (Azure AD) enumeration. Output: a local database of users, groups, applications, service principals and roles. Next: the offline map of the tenant. Query it for over-privileged service principals and stale app registrations — the Azure identity findings, enumerated.

azurehound: collects the Azure/Entra graph for BloodHound. Output: nodes and edges consumable in BloodHound. Next: turns Azure roles and ownership into the same attack-path graph used for on-prem AD, so Azure escalation becomes a shortest-path query rather than a manual trawl.

GCP: after the foothold

GCP escalation runs through a different primitive than AWS or Azure, so the enumeration targets it directly: service-account impersonation, not role assumption.

gcloud auth list then gcloud projects get-iam-policy <project>: establish identity and read the bindings. Output: the active account, and who holds what across the project. Next: the bindings rarely tell the whole story on their own, because GCP permissions inherit down the resource hierarchy — a grant three levels up is invisible here.

gcloud iam service-accounts get-iam-policy <sa>: read who can act on a service account. Output: the principals with roles on the service account. Next: this is the escalation question in GCP — iam.serviceAccounts.getAccessToken or actAs on a more privileged account is the two-hop path that most GCP compromises follow. ScoutSuite and Prowler both flag the exported-key and default-Editor findings that open it.

Where this connects

Every tool here serves the cloud pentesting methodology — the posture tools orient it, the exploitation tools execute it. What they enumerate is the offensive read of the identity pillar: AWS, Azure and GCP identity are the maps these tools are drawing, and the fixes are the architecture and guardrails those pages describe.