← Back to Labs L2 Intermediate

AWS · Detection · CloudTrail Evidence

AWS CloudTrail Detection Reasoning

Intermediate LAB for understanding how CloudTrail evidence supports detection reasoning for iam:PassRole, sts:AssumeRole, Lambda updates, Secrets Manager access, KMS decrypt, and workload identity activity.

Status Intermediate
Cloud AWS
Domain Detection
Track L2 Evidence

Overview

CloudTrail Detection Reasoning teaches how to interpret AWS API activity as security evidence. It moves the L2 track from access-control theory into investigation reasoning.

L2 Intermediate Detection reasoning CloudTrail evidence No live query

Concept Deep Dives

Expand these concepts when studying event evidence, investigation context, or detection logic.

What is CloudTrail?

CloudTrail records AWS API activity. It helps analysts understand who made a request, which API was called, which resource was targeted, when it happened, and whether the request succeeded or failed.

What is detection reasoning?

Detection reasoning is the process of turning raw event records into security meaning. The analyst asks whether the event is expected, risky, denied, successful, chained, or part of a larger path.

Why does iam:PassRole matter in CloudTrail?

PassRole events show when a principal attempted to attach or delegate a role to an AWS service. When paired with Lambda create or update activity, PassRole can indicate workload identity risk.

Why do Secrets Manager and KMS events matter together?

GetSecretValue shows secret retrieval. KMS Decrypt may show cryptographic access used to read protected secret material. Together, they can form a stronger evidence path than either event alone.

What should executives understand?

CloudTrail is evidence, not just logging. It helps prove whether sensitive access happened, whether a risky path was attempted, and whether control assumptions match real activity.

Visual CloudTrail Detection Model

Detection reasoning is easiest to understand as an evidence path from API call to investigation decision.

Principal / Workload User, role, session, function, or service identity
AWS API Call PassRole, AssumeRole, UpdateFunctionCode, GetSecretValue, Decrypt
CloudTrail Event Event source, event name, identity, resource, result, and time
Investigation Decision Expected, suspicious, denied, successful, or needs context
PassRole Role delegated to service
+
Lambda Update Function behavior changed
Workload Signal Investigate execution role and downstream access
GetSecretValue Secret retrieval event
+
KMS Decrypt Cryptographic access event
Data Access Evidence Correlate identity, key, secret, and session
Learning rule: CloudTrail tells the evidence story. The analyst still needs context to decide whether the event is expected, risky, or incident-worthy.

Example Scenario

A role updates Lambda code, then the workload accesses Secrets Manager and KMS.

CloudTrail signal path:
1. lambda:UpdateFunctionCode
2. secretsmanager:GetSecretValue
3. kms:Decrypt

Detection reasoning:
- Did the same identity or session initiate the path?
- Did the Lambda execution role retrieve the secret?
- Was this expected deployment behavior?
- Did KMS decrypt align with the secret access?
- Should this become a finding or investigation?

Authorization Links

Detection reasoning depends on understanding the underlying authorization model.

Bridge to Principal LABs

Principal LABs become more complete when learners can connect attack-path reasoning to evidence-path reasoning.

Governance Boundary

This lab is read-only and deterministic.

Runtime = source of truth
OPA = decision authority
Aegis = bounded intelligence
Frontend = rendering only
  • Does not query customer CloudTrail
  • Does not invoke AWS APIs against customer accounts
  • Does not deploy detection rules
  • Does not create alerts
  • Does not execute remediation
  • Does not create Shield findings
  • Does not create Aegis fixtures
  • Does not override OPA

Source Artifacts

  • metadata.json
  • architecture.md
  • index.html