Cross‑Service Signal Correlation to Detect Multi‑Stage AWS Attacks

AWS has sharpened its focus on stitching together alerts from GuardDuty, CloudTrail, VPC Flow Logs, DNS query logs, and S3 data events, and it now encourages teams to use CloudWatch Logs Insights to build their own cross‑service correlation queries. This shift lets security engineers, platform engineers, and DevOps practitioners move from reacting to isolated findings toward seeing the full sequence of a multi‑stage attack, which shortens investigation time and improves response precision.

Leverage the native detection services first

All of the services listed below generate findings that are already scoped to common threat patterns. Enabling and tuning them is the prerequisite for any custom correlation work.

• Amazon GuardDuty ingests CloudTrail events, VPC Flow Logs, DNS logs, and S3 data events, then emits high‑confidence findings such as Recon:IAMUser/* or Discovery:S3/*.
• Amazon Detective visualizes relationships between resources and GuardDuty findings, helping analysts trace lateral movement across accounts.
• AWS Security Hub aggregates findings from GuardDuty, Inspector, and other services onto a single prioritized dashboard.
• Amazon Security Lake stores all security‑related logs in the Open Cybersecurity Schema Framework (OCSF) format for long‑term analysis.
• Amazon Inspector adds vulnerability context to workload data, which can be correlated with activity logs.

Before writing any custom logic, confirm that each service is collecting the data you need and that its sensitivity settings are tuned to your environment. Suppressing known‑good patterns at this stage reduces noise in downstream queries.

Build custom cross‑service correlation in CloudWatch Logs Insights

CloudWatch Logs Insights lets you run ad‑hoc queries across the raw logs that feed GuardDuty and other services. A typical multi‑stage scenario includes an unfamiliar source IP calling GetCallerIdentity, a burst of List* and Describe* API calls that generate AccessDenied responses, and a subsequent data exfiltration to a newly registered domain. The following query demonstrates how to surface that pattern from CloudTrail logs:

fields @timestamp, eventName, sourceIPAddress, userIdentity.arn
| filter eventName in ["GetCallerIdentity", "List*", "Describe*"]
| filter sourceIPAddress != "known‑internal‑range"
| sort @timestamp asc
| limit 100

By extending the filter set to include VPC Flow Log records that show outbound traffic to the suspicious domain, you can produce a single timeline that links reconnaissance, privilege‑escalation attempts, and data exfiltration. The resulting view can be saved as a reusable Insight or fed into a Lambda function for automated remediation.

From manual queries to an automated pipeline

Once a reliable query is identified, the next step is to embed it in a repeatable workflow. Typical components include:

• A scheduled CloudWatch Event that triggers the query on a regular cadence.
• A Lambda function that evaluates the query results, enriches them with business context (e.g., asset criticality), and posts a custom finding to Security Hub.
• An SNS or EventBridge notification that alerts the incident‑response team and optionally invokes an automated containment playbook.

This pattern mirrors the “Extended Threat Detection” capability that GuardDuty already offers, but it gives you full control over the data sources, thresholds, and enrichment steps that matter to your organization.

Related CloudNinjas coverage: AWS.

What This Means For Practitioners

Practitioners should start by confirming that GuardDuty, Detective, Security Hub, Security Lake, and Inspector are all active and tuned for their workload. Next, prototype a CloudWatch Logs Insights query that captures the sequence of API calls and network flows relevant to their threat model. Finally, automate the query output into Security Hub or a custom alert channel to ensure that multi‑stage attacks are visible as a single incident rather than a collection of unrelated findings.