Skip to content
Home/Blog/AWS Cloud Detection: From CloudTrail to SecHub Cor...
Back to blog

AWS Cloud Detection: From CloudTrail to SecHub Correlation

2026-07-02

13 min

awsdetectioncloud-security

Cloud security is fundamentally different from on-premises security. Instead of endpoint agents and network taps, you have API logs. CloudTrail captures every API call. GuardDuty detects anomalies. Security Hub aggregates findings. But raw logs and detections are noise without correlation.

Building a detection pipeline means:

  1. Normalizing telemetry from multiple sources (CloudTrail, GuardDuty, Security Hub, VPC Flow Logs)
  2. Writing correlation rules that identify attack chains
  3. Generating analyst-ready findings with context and evidence

The Data Sources

CloudTrail: Records every API call to AWS services. Format: JSON with timestamp, principal (user/role), action, resource, and result.

Useful fields for detection:

  • userIdentity.principalId: who made the call?
  • eventName: what API call was made?
  • sourceIPAddress: from where was it called?
  • requestParameters and responseElements: what data was modified?
  • errorCode and errorMessage: did the call fail?

Signal detection:

  • Root account usage: any call where userIdentity.type == "Root" is high-priority. Root accounts should not perform daily operations.
  • Console login without MFA: CloudTrail logs ConsoleLogin events. If the event has additionalEventData.MFAUsed == false, the user logged in without second factor.
  • Sensitive API calls from unusual locations: CreateAccessKey, PutUserPolicy, DeleteTrail are dangerous. If called from an IP geographically distant from the user's normal location, it is suspicious.

GuardDuty: AWS's managed threat detection service. It ingests VPC Flow Logs, CloudTrail, and DNS logs to detect anomalies.

GuardDuty findings include:

  • UnauthorizedAccess:IAMUser/ConsoleLogin: multiple failed console login attempts
  • CryptoCurrency:EC2/BitcoinTool.B: EC2 instance running cryptocurrency mining
  • Trojan:EC2/Black.C: behavioral detection of EC2 instances with suspicious network patterns

The limitation: GuardDuty detects known patterns. Novel attacks, slow-moving lateral movement, and legitimate abuse of permissions often evade it.

Security Hub: Aggregates findings from GuardDuty, Config, IAM Access Analyzer, and third-party tools. Provides a single pane of glass for cloud security.

Building a Detection Pipeline

Raw telemetry is useless without processing. I built a pipeline (Sentinel Forge) that:

  1. Ingests CloudTrail events via S3 or CloudWatch Logs
  2. Normalizes them into a common event model
  3. Applies detection rules (YAML-defined)
  4. Correlates related events
  5. Generates findings with severity, confidence, and remediation steps

Detection Rule: Privilege Escalation via PassRole

One of the most exploited AWS primitives is iam:PassRole. Example attack:

  1. Attacker with limited permissions but iam:PassRole and lambda:CreateFunction
  2. Attacker creates an AWS Lambda function with a high-privilege IAM role attached
  3. Attacker invokes the Lambda function, which now executes with the high-privilege role
  4. Lambda can create more access keys, modify security groups, or exfiltrate data

Detection:

rule: privilege_escalation_via_passrole
name: "Privilege Escalation: IAM PassRole + Lambda"
events:
  - eventName: CreateFunction
    requestParameters.role: <high_privilege_role>
  - eventName: InvokeFunction
    sourceIPAddress: <attacker_ip>
    (within 5 minutes of CreateFunction)
severity: CRITICAL
remediation: "Review Lambda function; revoke IAM credentials if compromised"

The rule flags when a low-privilege user creates a Lambda function with a high-privilege role and then invokes it.

Detection Rule: Credentials in Config

AWS Config is a service that tracks resource state changes. An attacker might accidentally (or intentionally) store access keys or secrets in a Config resource.

Detection:

rule: credential_exposure_in_config
name: "Sensitive Data Exposure: Credentials in Config"
events:
  - resource_type: AWS::SecretsManager::Secret
    property_change: value
    new_value_contains: ^AKIA[0-9A-Z]{16}$  # AWS access key pattern
severity: CRITICAL
remediation: "Rotate exposed access key immediately"

Correlation: The Golden Chain

The hardest attack to detect is a slow-moving lateral movement that chains multiple, seemingly innocent actions.

Example:

  1. User A creates a new IAM role (harmless)
  2. User A attaches a policy granting s3:GetObject on all buckets (suspicious but maybe normal)
  3. User A creates an EC2 instance and assigns the new role to it (suspicious)
  4. The EC2 instance starts reading S3 buckets at high volume (exfiltration)

Each individual action might pass detection. But the chain is the attack.

Correlation rule:

rule: data_exfiltration_chain
name: "AWS Data Exfiltration: Privilege Escalation + EC2 Lateral Movement + S3 Bulk Read"
events:
  - eventName: CreateRole
    principal: <attacker_principal>
  - eventName: PutRolePolicy
    role: <created_role>
    policy_contains: s3:GetObject
    (within 30 minutes of CreateRole)
  - eventName: RunInstances
    requestParameters.iamInstanceProfile: <created_role>
    (within 1 hour of PutRolePolicy)
  - ec2_instance <id> starts reading S3 buckets
    bytes_transferred: > 1GB
    (within 2 hours of RunInstances)
severity: CRITICAL

This rule captures the chain: role creation, privilege escalation, EC2 setup, and exfiltration.

The Challenge: False Positive Tuning

Detection rules generate noise. Every rule fires on something-the question is whether that something is malicious or benign.

Example: "Root account API call" is a high-confidence signal of compromise. But during AWS account initialization or disaster recovery, the root account legitimately makes API calls.

Tuning:

  1. Baseline normal behavior: for each principal, establish what is normal (what API calls do they typically make? From what IP ranges? At what times?).
  2. Thresholding: instead of "any GetBucketPolicy call is suspicious," change it to "GetBucketPolicy called 50+ times in 10 minutes is suspicious."
  3. Contextual allow-listing: if a principal has made the same call 1000 times before, do not flag the 1001st time.

VPC Flow Logs and DNS Logs

CloudTrail and GuardDuty are API-level detections. But lateral movement and data exfiltration also happen at the network level.

VPC Flow Logs: record IP traffic within VPCs. Useful for detecting:

  • Unusual outbound connections from EC2 instances to external IPs
  • Port scanning or enumeration within the VPC
  • Unusual data volumes between instances

DNS Logs: via CloudWatch Logs or GuardDuty, capture DNS queries made by instances. Useful for detecting:

  • Attempts to resolve malware command-and-control domains
  • Data exfiltration via DNS tunneling
  • Reconnaissance (scanning for known AWS IPs or services)

Correlation: if an EC2 instance resolves a known C2 domain (via DNS logs) and then makes outbound HTTPS connections to that domain (via VPC Flow Logs), it is almost certainly compromised.

Lessons Learned

  1. Normalization is 80% of the work: before you can correlate, you need all events in a common format.
  2. Slow attacks win: traditional detections flag rapid, noisy attacks (1000 failed login attempts). Slow exfiltration (10GB over 30 days) is harder to detect.
  3. Correlation beats single-signal detection: one suspicious event is noise; three related events in sequence is an attack.
  4. Cloud logs are different: network tools (IDS/IPS) are less useful in cloud. API logs and behavioral analysis are more important.

Resources

  • AWS CloudTrail documentation and best practices
  • GuardDuty finding types and tuning
  • MITRE ATT&CK for AWS
  • Splunk Security Content for AWS monitoring
  • Elastic detection rules for AWS

The shift to cloud security is a shift from network-centric to API-centric defense. The skill is not deploying an IDS; it is reading logs, understanding attack patterns, and building pipelines that surface the signal in the noise.