← All walkthroughs

Cloud: a leaked key to account takeover

A single leaked access key becomes full control of a cloud tenant: enumerate, escalate IAM privileges, persist, and reach the data — mapped to the MITRE ATT&CK cloud matrix.

Public cloud (IaaS / identity) Intermediate CloudIAMIdentity
Authorized testing only. This is a conceptual, defensive-aware walkthrough that maps an attack path to MITRE ATT&CK, detection and mitigation, and links to references for the detail. It is not a copy-paste playbook. Use it only against systems you own or are explicitly permitted to test.

Scenario

An authorized cloud assessment. During recon you find a long-lived access key committed to a public repository that belongs to the in-scope tenant. The goal is to show how far that one key goes.

Practice this path: Cloud attacks · MITRE ATT&CK
  1. 1

    Initial Access

    Authenticate with the leaked credential

    T1552.001 Unsecured Credentials: Credentials In FilesT1078.004 Valid Accounts: Cloud Accounts

    Validate the discovered key against the cloud API and determine which identity it represents and whether it is still active, without changing any state.

    Detection

    First use of a key from a new IP/user-agent, and use of a credential that had been dormant, are classic cloud-audit anomalies.

    Mitigation

    Never commit secrets; use short-lived/federated credentials, secret scanning in CI, and automatic key rotation and revocation.

    References aws-iam-privesc
  2. 2

    Discovery

    Enumerate the identity's reach

    T1526 Cloud Service DiscoveryT1087.004 Account Discovery: Cloud AccountT1580 Cloud Infrastructure Discovery

    Inventory the services, roles, policies and resources this identity can see, and map its effective permissions to understand the blast radius.

    Detection

    Broad read/enumeration API calls (list*/describe*/get*) in a short window are visible in cloud audit logs.

    Mitigation

    Least-privilege IAM, deny-by-default policies, and alerting on bulk enumeration by a single principal.

    References aws-iam-privesc · azure-ad-security · gcp-security
  3. 3

    Privilege Escalation

    Escalate via an IAM misconfiguration

    T1098.003 Account Manipulation: Additional Cloud Roles

    Identify a permission that allows privilege escalation (for example attaching a more-privileged policy or role to yourself) and use it to obtain administrative rights within the authorized tenant.

    Detection

    IAM policy/role modifications and self-privilege grants are high-value audit events.

    Mitigation

    Remove dangerous IAM actions from everyday roles, require approvals for policy changes, and continuously scan for escalation paths.

    References aws-iam-privesc
  4. 4

    Persistence

    Establish durable access

    T1098.001 Account Manipulation: Additional Cloud CredentialsT1136.003 Create Account: Cloud Account

    Where in scope, demonstrate persistence by adding an additional credential or creating a new principal, clearly labelled and documented for removal.

    Detection

    Creation of new access keys, users or service principals outside change windows is a strong indicator.

    Mitigation

    Guardrails that prevent/alert on new principals and keys, and periodic review of all credentials and identities.

    References aws-iam-privesc · azure-ad-security
  5. 5

    Defense Evasion

    Understand the logging the attacker can reach

    T1685.002 Disable or Modify Tools: Disable or Modify Cloud Log

    Assess (do not disable in production) whether the compromised identity could tamper with cloud logging — a key finding for the report, since it shows whether the blue team would retain evidence.

    Detection

    Changes to logging/trail configuration are among the most critical cloud alerts.

    Mitigation

    Centralize logs to a separate, append-only account, and deny log-configuration changes to workload identities.

    References aws-iam-privesc
  6. 6

    Collection / Exfiltration

    Demonstrate impact on the data

    T1530 Data from Cloud StorageT1537 Transfer Data to Cloud Account

    Prove access to sensitive cloud storage to the extent the rules of engagement allow, documenting what could be read or moved rather than actually exfiltrating customer data.

    Detection

    Large or unusual reads from storage and transfers to external accounts are visible in data-plane logs.

    Mitigation

    Encrypt and tightly scope storage access, enable data-plane logging, and block cross-account transfers by policy.

    References aws-iam-privesc

Key takeaways

  • One long-lived key in a public repo can equal tenant takeover when IAM is permissive.
  • Short-lived credentials, secret scanning and least-privilege IAM remove most of this path.
  • Append-only, out-of-account logging is what guarantees the blue team keeps evidence even against an admin-level attacker.