The first question to understand about cloud attacks is how threat actors gain unauthorized access. According to the Google Threat Horizons report in both H1 and H2 of 2025, weak or absent credentials, misconfigurations, and API/UI compromises accounted for the initial access vectors in over 80% of observed threat actor activity. ^{[1] [2]}

Weak or Absent Credentials

These have consistently been the most targeted initial access vector in cloud environments. When combined with a lack of Multi-Factor Authentication (MFA) and poor permissions management, a single effective social engineering attempt can give a threat actor broad access to the environment and enable them to carry out their objectives.

Misconfigurations

Many organizations transitioned to the cloud without an equivalent depth of expertise in cloud security. The skills gap created by this transition, combined with insufficient change control and human error, has led to numerous incidents resulting from the exploitation of cloud misconfigurations. Whether the misconfiguration exposes data that should be restricted or grants excessive privileges that enable lateral movement, threat actors are actively scanning for and exploiting these weaknesses.

API/UI Compromise

Organizations deploying cloud workloads across worldwide regions benefit from improved end-user accessibility. However, if proper access controls are not in place, these applications can be exposed to the internet, creating a broad attack surface. Combined with weak credentials or vulnerable software, threat actors can gain an initial foothold through these exposed interfaces. Once a foothold is established, reconnaissance of the hosts running those workloads may lead to lateral movement to other hosts or, in the worst case, into the management plane.

Once threat actors gain access to a cloud environment, several important trends emerge in attacker objectives. Mandiant’s M-Trends 2025 Report provides insight into threat actor motivations:

> ... data theft was observed in nearly two-thirds of cloud compromises (66%). > Over a third of cases (38%) served financially motivated goals, including data theft extortion without ransomware encryption (16%), business email compromise (BEC) (13%), ransomware (9%), as well as cryptocurrency theft and employment fraud. ^[3] > — Mandiant, M-Trends 2025 Report

Cloud environments host vast amounts of valuable data across storage services, databases, and compute workloads. Orca Security’s 2025 State of Cloud Security Report found that:

In cases like these, attackers need zero or minimal permissions to access sensitive data.

Amazon GuardDuty is a managed threat detection service that continuously monitors AWS accounts and workloads for malicious activity and unauthorized behavior. It uses machine learning, anomaly detection, and integrated threat intelligence to identify potential threats such as cryptomining, compromised credentials, or communication with known command-and-control servers.

Within the GuardDuty interface, analysts can review a list of findings across resources in the environment. Examining an individual finding provides an in-depth view of the identities, resources, and indicators associated with it, giving responders a starting point for deeper investigation.

GuardDuty also offers agentless malware scanning for EC2 instances and container workloads through its Malware Protection feature. When GuardDuty generates a finding indicating potential malware, it can automatically trigger a scan by creating snapshots of the EBS volumes attached to the affected instance. Because scanning operates on snapshots rather than live volumes, there is no performance impact on running workloads. Responders can also manually initiate on-demand scans by specifying an EC2 instance ARN, which is useful for investigating hosts that have not yet triggered an automated finding. When malware is detected, EBS snapshots are retained to preserve forensic evidence for deeper analysis. This combination of automated detection and evidence preservation makes GuardDuty a valuable first step in AWS cloud incident response workflows.

Azure detection capabilities can be added to a cloud environment by enabling Microsoft Defender for Cloud. Defender for Cloud monitors both the resources in the environment and Microsoft 365 and Azure audit logs for suspicious activity.

Figure 3 shows an example of an alert for a SQL injection attack against an Azure SQL database. As with GuardDuty, the alert provides context about the resources involved and indicators to support the start of an investigation.

From an incident response perspective, Defender for Cloud’s alert interface includes a "Take action" tab that provides several response options directly from the alert. Responders can inspect the resource’s activity logs for additional context, review manual remediation steps specific to the alert type, or trigger an automated response through an Azure Logic App. Alerts are also mapped to MITRE ATT&CK kill chain stages where applicable, helping analysts understand the attacker’s progression through the environment. For organizations using Microsoft Sentinel or another SIEM, Defender for Cloud alerts can be streamed directly to those platforms for centralized investigation alongside other log sources.

Google Cloud offers native threat detection via Security Command Center (SCC). SCC includes several detection services that cover different parts of the environment:

Each of these services generates findings that responders can review, annotate, and prioritize by severity. Findings include the affected resource, the detection source, and recommended remediation steps. The SCC interface follows a similar pattern to GuardDuty and Defender for Cloud, presenting a consolidated view of findings across the environment with drill-down capability into individual alerts.

For investigation, findings can be exported to BigQuery for deeper analysis or published to Pub/Sub for integration with external SIEM platforms and ticketing systems. Organizations using Google Security Operations (formerly Chronicle) can stream SCC findings directly into their SIEM for correlation with other log sources. SCC also supports automated playbooks for remediation, allowing organizations to define response actions that execute when specific finding types are generated.

While cloud-native detection services provide valuable coverage, they have limitations that responders should understand. These tools focus primarily on control plane events and known attack patterns, which means they may miss activity that falls outside their detection models.

First, cloud-native detections typically focus on known patterns. Novel techniques or living-off-the-land approaches that use legitimate cloud APIs in unusual ways may not trigger alerts. An attacker who uses only the permissions already assigned to a compromised identity is difficult to distinguish from normal operations.

Second, most cloud-native detection services monitor the control plane, leaving data plane activity largely unmonitored unless additional features are enabled. An attacker downloading sensitive files from a storage bucket will not generate a detection unless data plane logging and associated detection rules are configured.

Third, these services lack organizational context. They do not know that a specific service account runs only during business hours, or that a particular user has never accessed a given resource. Without organization-specific baselines, anomalous behavior that would be obvious to an analyst may not trigger an alert.

Organizations should treat cloud-native detection services as a foundation, not a complete solution. Supplementing them with a SIEM that can apply custom detection rules, cross-correlate events across sources, and incorporate organizational baselines significantly improves detection coverage.

One of the most important steps in responding to cloud incidents is scoping the compromise. Cloud environments often require more considerations and access controls than traditional on-premises environments.

Start by identifying what identity or identities are compromised. These could be users, access keys, or service accounts; in the case of AWS, even a role can be compromised. Once compromised identities are identified, scope the permissions assigned to those identities to understand what the threat actor could access.

This is often not as simple as looking at the individual identity and seeing a list of permissions. In Azure, for example, permissions are granted through role assignments, which bind an identity, role, and resource to define which actions can be taken. The examples in Figure 4, Figure 5, and Figure 6 show how permissions are granted at the subscription level and resource group level, and how that impacts the scope of a compromise. We can collect similar information using the Azure CLI, as shown in Listing 2, to list all role assignments for a user across the entire subscription.

Google Cloud uses a similar concept called bindings, where an IAM policy binds a member (user, service account, or group) to a role on a specific resource. Bindings are applied at different levels of the resource hierarchy (organization, folder, project, or individual resource), and permissions are inherited downward. Responders can use the gcloud projects get-iam-policy command to list all bindings for a project and identify the effective permissions of a compromised identity.

Beyond direct role assignments, additional mechanisms may change the true scope of an identity compromise. A compromised identity in AWS may appear able to manage users in an account, but a permission boundary, Service Control Policy (SCP), session policy, or resource-based policy could ultimately prevent those actions after the full access evaluation flow. Understanding the full policy evaluation chain is important for accurately scoping what a compromised identity can actually do.

In AWS, the policy evaluation logic follows a specific order: first, explicit denies in any applicable policy take precedence; then, organization SCPs are evaluated, followed by resource-based policies, identity-based policies, IAM permission boundaries, and finally session policies. At each layer, an explicit deny overrides any allow. This means a compromised identity with AdministratorAccess may still be unable to perform certain actions if an SCP or permission boundary restricts them. AWS documents this evaluation chain in detail in the IAM User Guide, and responders should reference it when the apparent permissions do not match observed behavior.

After identifying affected identities, identify affected resources. This helps establish the threat actor’s actions in the environment and determine whether unauthorized changes were made. For storage accounts, buckets, and other data stores, the organization will want to know whether any data was exposed. Certain resources could also facilitate lateral movement. Virtual machines in the cloud often host an Instance Metadata Service (IMDO) service that provides access tokens to service accounts or roles, which can then be used to escalate privileges.

Finally, examine the cloud network architecture to evaluate potential lateral movement. If the compromised cloud environment has direct access to additional cloud organizations within the same provider, the on-premises environment, or another cloud provider, there may be additional logs to collect and analyze to determine whether those connected environments were also compromised.

We mentioned during preparation the importance of enabling and centralizing logs prior to incidents. This section discusses control-plane and data-plane logs, what data they contain, and their relevance to incident response.

Management/control plane logs record Identity and Access Management (IAM) events, administrative events, and resource management events. As mentioned earlier, these logs are enabled by default.

IAM events are one of the most critical categories available during an investigation. For initial access, these logs help determine who logged in, when, from where, and how.

Additional context in these logs, such as success/failure status and login method, provides a more complete picture of the intrusion. The example in Listing 3 from an Azure sign-in log shows that a user correctly authenticated with their password but failed both MFA attempts. This pattern could indicate that a password was successfully stolen but MFA controls are preventing a compromise.

Once access is gained, IAM logs provide insight into persistence or privilege escalation activities, such as creating new users or assigning additional roles to compromised accounts. Depending on the attacker’s tactics and techniques, organization-level management events may also appear, such as changes to logging configuration or domain settings.

Resource management events include the creation, deletion, starting, and stopping of resources. These events provide significant insight into attacker intentions. Attempts to perform destructive attacks by deleting critical resources would appear in these logs, as would the creation of GPU-enabled virtual machines that may indicate a cryptomining attack. The CloudTrail event in Listing 4 shows a RunInstances call launching a p3.2xlarge GPU instance, a common indicator of cryptomining activity. Details worth noting include the instance type, the region (attackers often target regions the organization does not normally use), and the identity that initiated the request.

Data plane logs, also known as resource logs, contain resource-level operations. These logs are off by default, but without them, responders often lack the full picture of an incident. Table 2 illustrates the difference between what each log plane captures for common cloud resources.

Consider an incident where an attacker accesses sensitive files in an S3 bucket. Control plane logs (CloudTrail) would show if the attacker modified the bucket policy, but only S3 server access logs or CloudTrail data events would reveal which specific objects were downloaded. Similarly, if initial access was gained by compromising a public-facing virtual machine, only the operating system logs on the endpoint or network flow logs on the VPC would show evidence of the access vector.

Without data plane logs, responders may be able to confirm that a resource was compromised but not what the attacker did with it. This gap directly affects the organization’s ability to assess data exposure and meet breach notification requirements.

IMPORTANT: Without data-plane logs, a breach notification assessment may be impossible. Regulatory frameworks such as GDPR, HIPAA, and PCI DSS require organizations to determine which data was accessed during a breach. If the only available logs show that a policy was changed but not what objects were subsequently downloaded, the organization may be forced to assume worst-case exposure and notify all affected parties.

Together, control-plane and data-plane logs allow responders to trace an attacker’s path through a cloud environment. Understanding which log sources are available and what they capture is essential for building a complete timeline of attacker activity.

When a virtual machine is compromised, it may seem like the only option is to shut down the host. There is a better approach that maintains the host for deeper analysis and provides insight into the threat actor’s intent. With virtual network controls, we can isolate VMs in a configuration that blocks inbound and outbound traffic, except for designated forensic networks. Combined with flow logs on the isolated subnet or compromised host, we can monitor what an active threat actor or malware infection is trying to do.

For example, using the Azure CLI, analysts can create a Network Security Group (NSG) with rules designed to deny all access except for a designated forensics subnet, as shown in Listing 5. This approach keeps the VM running for continued observation while cutting off the threat actor’s access.

Data exfiltration is one of the top impacts of cloud compromises, and some of the most valuable data resides in storage accounts or buckets. A simple misconfiguration of a storage resource with sensitive data can easily lead to exposure, and threat actors are constantly running automated scanners to find misconfigured buckets.

If a bucket has been compromised during an incident, it is important to quickly resolve any misconfigurations to prevent further data exposure. The specific remediation procedures vary by cloud provider.

AWS

S3 buckets can be restricted using a combination of Block Public Access settings and policies. Block Public Access overrides any configurations applied via policies or ACLs, making it the most effective first step for stopping exposure. IAM or resource-based policies can then be applied to specify which users can take what actions on which buckets. In legacy configurations, Access Control Lists (ACLs) may control access. These are important to check during a compromise, as attackers can abuse them, but ACLs should not be used for new access control configurations.

The commands in Listing 6 show how to restrict public access on each provider.

To assess exposure on AWS, review S3 server access logs or CloudTrail data events for the bucket to identify what objects were accessed and by whom. The s3logparse tool can simplify the analysis of S3 server access logs during an investigation. ^[8]

Azure

If anonymous read access has been granted to an Azure storage resource, it is configured at either the container level or the blob level, with container-level settings overriding blob-level settings. A user with permissions to set AllowBlobAnonymousAccess should change the settings to prevent anonymous access before further exposure occurs on containers that should not be public.

Google Cloud

Permissions on Google Cloud buckets are controlled in two ways: IAM policies and ACLs. To remediate an exposed bucket, apply IAM policies granting only the permissions needed to the users who need them. As with AWS, ACLs are a legacy option that should be checked during a compromise investigation but should not be used for remediation. If both ACLs and IAM permissions are in place, only one needs to allow access for it to be granted, so checking IAM permissions alone is not sufficient.

Time is a factor when remediating exposed storage. Automated scanners continuously probe for misconfigured buckets, and public exposure can be discovered and exploited within hours of misconfiguration. Once access controls are corrected, responders should verify the remediation by attempting to access the resource from an unauthenticated context to confirm that public access is no longer possible.

Each of these providers has detailed documentation on access controls, but this overview should point responders in the right direction when a storage resource is compromised.

IAM is one of the most important services in cloud environments, and it is also one of the easiest places for a threat actor to establish persistence with the right permissions. In addition to reviewing IAM logs, responders should directly examine IAM resources for any recently created or modified items. Areas to examine include:

The CLI commands in Listing 7 can help identify common IAM persistence mechanisms across the major cloud providers.

Revoking credentials alone is not sufficient if active sessions remain valid. Cloud provider tokens typically remain valid until they expire, even after the underlying credential is rotated. Responders should revoke active sessions in addition to rotating credentials:

These persistence mechanisms should be reviewed as part of any cloud compromise investigation, as they represent the most common methods for regaining access after an initial response.

For compute services, responders should consider virtual machines, containers, and serverless functions, all of which can be backdoored. For virtual machines, the most common methods of retaining access include:

Startup scripts are particularly effective because they re-execute each time the instance boots, surviving reboots and even redeployments from the same image.

For containers, the container registry can be poisoned to ensure newly created instances include backdoors. Responders should compare running container images against known-good digests in the registry and review any recently pushed images for unauthorized modifications.

Serverless functions are a frequently overlooked persistence vector. An attacker with sufficient permissions can create a Lambda function, Azure Function, or Cloud Function that executes on a schedule or in response to events, periodically creating new access keys or exfiltrating data. Because serverless functions do not have a persistent host, traditional endpoint monitoring cannot detect them. Responders should list all functions across regions and review their triggers, code, and execution history, as shown in Listing 8.

The challenge with many of these techniques is that they either do not appear in logs or the log entries lack sufficient context to identify the persistence mechanism. For virtual machines, control-plane logs capture instance creation and modifications to startup scripts, but the contents of the scripts themselves are not logged. For serverless functions, the control plane captures function creation and updates, but the function code and its execution output require separate log sources (such as CloudWatch Logs for Lambda). Investigation often requires host forensics or manual review of resources in the cloud console to identify these backdoors.

Network resources are critical security controls that, with simple modifications, can open access to both the original threat actor and new ones. A single network security group or ACL change can make a previously restricted resource accessible from the internet. More advanced techniques include creating persistent VPN tunnels or reconfiguring DNS settings to redirect traffic.

These are common persistence techniques, but they are not a comprehensive list. Responders should review network configurations as part of eradication and compare the current state against known-good baselines where available.

Across all three categories, the common thread is that cloud persistence often requires only API-level access rather than host-level compromise, making it faster to establish and harder to detect through traditional endpoint monitoring.

Cloud compute resources and infrastructure-as-code templates provide a modern way to equip responders with forensic workstations. Rather than distributing physical workstations to work locations, organizations can deploy pre-configured virtual machines with the compute and memory resources needed for intensive forensics workloads. These images can be maintained with current tooling and deployed on demand, ensuring responders always have access to a consistent, up-to-date analysis environment. Infrastructure-as-code tools such as AWS CloudFormation, Azure Resource Manager templates, or Terraform enable forensic environments to be created and destroyed with a single command. This makes it practical to spin up a fresh workstation for each investigation and tear it down when the case is closed.

In cases where forensic integrity is critical, cloud storage simplifies the management of evidence that requires a chain of custody. Cloud storage provides effectively unlimited capacity at relatively low cost, with built-in logging capabilities that create an audit trail documenting any access. Access controls and retention policies can restrict access to read-only for authorized personnel and automatically archive or delete data based on organizational policies.

Cloud providers also offer immutable storage configurations that prevent evidence from being modified or deleted, even by administrators. The AWS CLI example in Listing 10 demonstrates how to configure an S3 bucket with Object Lock, which enforces write-once-read-many (WORM) protection on stored evidence.

Azure Blob Storage offers a similar capability through immutable storage policies, and Google Cloud Storage supports retention policies with bucket lock. Regardless of the provider, the principle is the same: forensic evidence should be stored in a way that prevents tampering and provides a verifiable chain of custody.

VPC flow logs capture metadata about network traffic flowing through cloud network interfaces, without requiring specialized hardware or packet-capture infrastructure. While flow logs do not capture packet payloads, they provide valuable context for investigations involving network-based attacks, lateral movement, or data exfiltration. Each flow log record includes source and destination IP addresses, ports, protocol, bytes transferred, and an accept or reject action, giving responders enough detail to identify communication patterns, detect data exfiltration volumes, and confirm whether network isolation controls are working as intended.

Flow log data can be directed to cloud storage or log analytics services for long-term retention and analysis, enabling reconstruction of network communication patterns during an investigation. Because flow logs operate at the network layer, they complement control plane logs by providing visibility into traffic that cloud management APIs do not capture, such as lateral movement between instances within the same VPC or outbound connections to attacker-controlled infrastructure.

Even without a fully automated response pipeline, containers and serverless services can accelerate triage and response. Forensic scripts can be containerized or deployed as serverless functions to gather and analyze evidence with minimal overhead.

NOTE: Velociraptor is an open-source endpoint monitoring and digital forensics tool that uses a lightweight agent to collect artifacts, including file system metadata, running processes, event logs, and memory from target hosts. It supports real-time hunting queries across large fleets using its own query language (VQL).

For example, a containerized Velociraptor server can be deployed in minutes to collect endpoint telemetry from compromised hosts across the environment. Using a container orchestration service, such as Amazon ECS, Azure Container Instances, or Google Cloud Run, responders can launch a prebuilt Velociraptor server image, connect agents to target hosts, and begin collecting artifacts without provisioning or configuring a dedicated server. When the investigation is complete, the container can be stopped and the collected data preserved in cloud storage.

Listing 11 demonstrates how to deploy a Velociraptor server on Amazon ECS using the AWS CLI. This creates a Fargate task that runs the Velociraptor frontend, exposes the GUI and client communication ports, and stores collected artifacts in an EFS volume.

Azure Container Instances and Google Cloud Run support similar deployments with their respective CLI tools, following the same pattern of container image, port mapping, and persistent storage configuration.