AWS has outlined how security teams can identify multi-stage cloud attacks by connecting signals across identity, storage, network, and DNS logs.
A single security alert may show that something unusual occurred. However, attackers rarely stop after one action.
Stolen credentials can be used to explore cloud resources, escalate privileges, move across accounts, access sensitive data, and send it outside the environment.
Correlating these events helps defenders see the complete attack chain rather than handling separate alerts one at a time.
For example, an identity may call GetCallerIdentity from an unknown IP address. Minutes later, the same identity may perform many List, Describe, or Get actions across AWS services, including failed requests marked AccessDenied.
A large outbound data transfer to a newly registered domain could then indicate possible data exfiltration.
Amazon GuardDuty can detect many such signals using AWS CloudTrail, Amazon S3 data events, VPC Flow Logs, DNS logs, runtime data, and other sources.
GuardDuty Extended Threat Detection can automatically correlate some activity into a high-severity attack sequence, including credential compromise followed by data theft.
It also provides a timeline, MITRE ATT&CK mapping, and remediation guidance.
Detecting Multi-Stage AWS Attacks
AWS said that automated detection services identify patterns common across many customer environments.
However, they do not know which S3 buckets contain sensitive data, which IAM roles should access them, which role-assumption paths are approved, or when production changes are allowed.
This business context can turn normal-looking cloud activity into a meaningful alert.
Security teams can build custom correlations in Amazon CloudWatch Logs Insights using CloudTrail, VPC Flow Logs, and Route 53 Resolver query logs.
One example is detecting bulk reads from a sensitive S3 bucket by an unexpected IAM principal.
Teams can identify high volumes of GetObject events, compare the principal against an approved-reader list, and then check whether the same source generated unusually large outbound network traffic.
CloudTrail data events must be enabled for monitored S3 buckets because management events alone do not record GetObject activity.
AWS recommends baselining normal access over time and setting alert thresholds above typical activity to reduce false positives.
AWS recommends tracking identity as a main correlation key across services. Analysts should also use attack-specific time windows, since automated activity may happen within minutes while manual reconnaissance can unfold over hours or days.
Organizations can automate detection logic with AWS Lambda, Amazon EventBridge Scheduler, Amazon SNS, and AWS Security Hub.
A Lambda function can query CloudTrail logs for unexpected high-volume S3 access, map an EC2-linked role to its private IP address, check VPC Flow Logs for large external transfers, and send an alert when both signals match.
For larger environments, AWS suggests centralizing telemetry through Amazon Security Lake or querying long-term records with Amazon Athena. Data can also be normalized using the Open Cybersecurity Schema Framework.
Detect, investigate, and respond faster with in-browser data inspection from ANY.RUN-> Power your SOC with ANY.RUN
