Cloud Post-Exploitation: What are the Next Steps for Hackers After Cloud Intrusion?

Upon gaining access to a cloud environment (e.g., by executing a reverse shell on a compromised EC2 instance or obtaining a set of temporary credentials), an attacker is effectively blind. They do not immediately know who they are, what permissions they possess, or what resources exist in the environment. The first step is rapid, stealthy enumeration to gain situational awareness.

Determining the IAM Context

The immediate priority is to answer the question, "Who am I?" In AWS, this is typically achieved by invoking the Security Token Service (STS). An attacker will execute a command like aws sts get-caller-identity. This command is the cloud equivalent of whoami. It returns the Account ID, the User ID, and the exact Amazon Resource Name (ARN) of the compromised identity. If the ARN indicates an assumed role (e.g., arn:aws:sts::123456789012:assumed-role/WebRole/i-0abcd1234), the attacker knows they are operating with temporary credentials tied to a specific resource, rather than a long-term IAM user.

Enumerating Permissions and Blast Radius

Once the identity is known, the attacker must determine what that identity is permitted to do. This is a complex challenge because cloud permissions are often a convoluted web of inline policies, attached managed policies, and resource-based policies. Attackers will attempt to list their own policies using API calls like iam:ListAttachedUserPolicies or iam:ListRolePolicies. However, defenders often restrict these enumeration permissions. In such cases, attackers rely on "brute-force" enumeration using specialized Red Team tools like Pacu or Cloudmapper. These tools script thousands of read-only API calls (e.g., s3:ListBuckets, ec2:DescribeInstances, rds:DescribeDBInstances) to systematically map out exactly which actions succeed and which return AccessDenied errors. This establishes the initial "blast radius" of the compromised credentials.

Resource Discovery

With a grasp on permissions, the attacker pivots to discovering valuable targets. They will systematically iterate through different geographic cloud regions and query the control plane to map the infrastructure. They look for exposed S3 buckets containing sensitive data, EC2 instances running vulnerable legacy applications, Lambda functions with hardcoded secrets in their environment variables, and KMS keys used for encryption. This discovery phase is conducted entirely via the cloud provider's APIs, rendering traditional network-based IDS/IPS solutions completely blind to the reconnaissance activity.

If the initial foothold only provides limited, low-level access, the attacker must escalate their privileges to achieve their objectives. Cloud privilege escalation rarely involves kernel exploits or buffer overflows; instead, it relies entirely on exploiting misconfigurations and logical flaws within the IAM architecture.

Exploiting IAM Misconfigurations

IAM systems are notoriously complex, and administrative errors frequently create unintended escalation paths. If an attacker possesses a specific, seemingly benign combination of permissions, they can exploit them to gain full administrative control.

A classic example involves the iam:PassRole permission. This permission allows an identity to pass a specific IAM role to a cloud service (like an EC2 instance). If a compromised low-privilege user has iam:PassRole for an Administrator role, AND the permission to launch a new EC2 instance (ec2:RunInstances), the attacker can simply launch a new instance and attach the Administrator role to it. The attacker then logs into that new instance (e.g., by injecting their own SSH key during launch) and subsequently operates with full administrative privileges.

Other dangerous IAM permissions that facilitate escalation include:

• iam:CreateAccessKey: Allows the attacker to generate a new access key for a highly privileged user, bypassing their password and MFA requirements.
• iam:AttachUserPolicy: Allows the attacker to attach the AdministratorAccess managed policy directly to their own compromised user account.
• iam:UpdateAssumeRolePolicy: Allows an attacker to modify the trust relationship of an existing administrative role, granting themselves the ability to assume it.

Abusing the Instance Metadata Service (IMDS)

When an attacker compromises a compute instance (like a virtual machine or a container), their immediate target is the Instance Metadata Service (IMDS). The IMDS is a localized HTTP endpoint (typically 169.254.169.254) that cloud providers use to supply the instance with configuration data, including temporary IAM credentials associated with the instance's assigned role. If an attacker finds a Server-Side Request Forgery (SSRF) vulnerability in a web application hosted on the instance, they can force the application to query the IMDS endpoint and return the temporary security credentials. The attacker can then extract these credentials and use them externally via the AWS CLI, effectively hijacking the instance's IAM identity. While cloud providers have introduced more secure versions of the metadata service (like IMDSv2 in AWS, which requires a session token), many environments still operate the legacy, highly vulnerable versions.

Lateral movement in the cloud does not solely mean moving from one IP address to another within a VPC. It primarily involves moving across different IAM identities, different cloud accounts, and traversing the boundary between the cloud and on-premises infrastructure.

Cross-Account Role Assumption

Modern enterprise cloud architectures are rarely confined to a single account. They utilize multi-account strategies (like AWS Organizations) to segregate development, testing, and production environments. Lateral movement often involves pivoting from a compromised, less-secure development account into the highly restricted production account. This is achieved by identifying and exploiting cross-account trust relationships. If a role in the compromised Dev-Account is trusted to assume a specific role in the Prod-Account, the attacker simply executes the sts:AssumeRole API call, passing the ARN of the target production role. If successful, the cloud provider grants the attacker temporary credentials to operate within the production environment, seamlessly traversing the account boundary without triggering network alarms.

Agent-Based Lateral Movement (SSM and RunCommand)

To move between compute instances, attackers increasingly avoid traditional methods like SSH or RDP, which are heavily monitored and require managing keys or passwords. Instead, they abuse native cloud management agents. Tools like AWS Systems Manager (SSM) Run Command or Azure Custom Script Extensions allow administrators to execute commands on fleets of servers simultaneously, directly through the cloud control plane, bypassing network firewalls and security groups. If an attacker gains access to an IAM identity with SSM execution permissions, they can silently deploy malware, extract memory dumps, or establish reverse shells on any managed instance in the environment without ever opening a traditional network port.

To ensure continuous access to the environment even if the initial entry point is discovered and remediated, attackers establish persistence mechanisms. Cloud persistence focuses on creating stealthy backdoors within the control plane itself.

Backdooring IAM and Identity Providers

The most direct method is manipulating the IAM infrastructure.

• Shadow Admins: Creating a new, hidden IAM user and assigning it a seemingly innocuous name (e.g., audit-service-account) while granting it deep administrative privileges via inline policies that are harder to detect than managed policies.
• Access Key Generation: Generating a second set of access keys for an existing, legitimate administrator user.
• IdP Manipulation: In highly sophisticated attacks, threat actors may target the Identity Provider federation trust. By modifying the SAML configuration to trust an external IdP controlled by the attacker, they can mint valid authentication tokens for any user in the directory, effectively establishing a master key to the cloud environment.

Infrastructure and Serverless Backdoors

Attackers also leverage cloud resources to maintain access.

• Security Group Modification: Modifying a VPC Security Group to allow inbound SSH or RDP access from a specific, attacker-controlled external IP address.
• Lambda Backdoors: Creating a hidden serverless function (e.g., an AWS Lambda function) designed to execute a reverse shell or exfiltrate data. The attacker then configures an EventBridge rule to trigger this malicious function automatically—perhaps every night at 3 AM, or whenever a specific API call is made, ensuring the backdoor is highly resilient and event-driven.
• Container Image Tampering: Poisoning the organization's private container registry (like Elastic Container Registry) by uploading a malicious Docker image that overwrites a legitimate service. The next time the environment autoscales, it will pull and execute the attacker's backdoored image.

The culmination of the post-exploitation lifecycle is achieving the objective, which typically involves monetizing the breach.

Snapshotting and Cross-Account Sharing

Exfiltrating massive databases (e.g., hundreds of gigabytes) over the network is slow and highly likely to trigger Data Loss Prevention (DLP) alerts or VPC Flow Log anomalies. Attackers have adapted by using the cloud provider's own infrastructure for exfiltration. If the attacker has permissions to manage Elastic Block Store (EBS) volumes or Relational Database Service (RDS) instances, they will take a point-in-time snapshot of the database drive. They then modify the permissions of that snapshot to share it publicly, or more stealthily, share it explicitly with an external AWS account controlled by the attacker. The attacker then mounts that snapshot in their own environment and extracts the data at their leisure, completely bypassing the victim's network perimeter and DLP controls.

S3 Exfiltration and Ransomware

For object storage, attackers utilize the aws s3 sync command using compromised credentials to rapidly drain buckets to an external location. Alternatively, they may exploit overly permissive bucket policies that allow anonymous public access. The cloud has also become a prime target for ransomware. Because cloud storage is highly centralized, an attacker who compromises the central Key Management Service (KMS) can execute devastating ransomware attacks without deploying traditional encrypting malware. They simply re-encrypt the S3 buckets with a KMS key they control, and then permanently delete the victim's original KMS keys. Without the original keys, the data is instantly rendered permanently inaccessible, forcing the organization to pay the ransom or lose their entire digital infrastructure.

Defending against advanced cloud post-exploitation requires a paradigm shift from network-centric defense to identity-centric and API-centric defense.

1. Strict Adherence to Least Privilege: Implement highly granular IAM policies. Relentlessly identify and remediate toxic permissions (like iam:PassRole combined with compute access) and utilize tools like IAM Access Analyzer to detect unintended public exposure.
2. Continuous Control Plane Monitoring: The control plane logs (AWS CloudTrail, GCP Audit Logs) are the most critical source of truth. Security Information and Event Management (SIEM) solutions must be configured with aggressive alerting rules to detect anomalous API activity, cross-account role assumptions, and the rapid creation of new identities.
3. Leverage Cloud-Native Threat Detection: Enable services like Amazon GuardDuty, Azure Security Center, or Google Cloud Security Command Center. These tools utilize machine learning to automatically baseline normal API behavior and flag anomalies that indicate post-exploitation activity, such as instances querying domains associated with known command-and-control servers or unusual IAM credential usage.
4. Secure the Metadata Service: Mandate the use of secure metadata services (e.g., requiring IMDSv2 across all AWS environments) to drastically reduce the risk of SSRF attacks leading to credential compromise.