Lion Cipher Lab

Engineer detections over Google Cloud Audit Logs: catch a service-account impersonation chain (offline)

• Cloud Security
• Advanced
• ~90 min
• Free · no account required

Why it matters

The GCP authorization lab in this catalog proved that the signature Google Cloud privilege escalation is service-account impersonation: hold iam.serviceAccounts.getAccessToken on a service account and your effective permissions become that account's, transitively, across projects and folders. That lab answered 'who CAN do this?'. This lab answers the question a defender actually gets paged for: 'is someone doing it RIGHT NOW, and can I prove it from the logs?'. The honest answer is uncomfortable. A room of cloud engineers will tell you Cloud Audit Logs record everything -- and they are wrong…

What you'll learn

• Reading the real Cloud Audit Log entry shape -- protoPayload with @type type.googleapis.com/google.cloud.audit.AuditLog, serviceName, methodName, authenticationInfo.principalEmail, authorizationInfo, resourceName, requestMetadata.callerIp -- and telling Admin Activity logs from Data Access logs by their logName
• Building a deterministic synthetic log stream that mixes benign noise with a planted multi-stage attack, so you can measure a detection instead of asserting it
• Writing a CORRELATION detection: SetIamPolicy granting roles/iam.serviceAccountTokenCreator -> GenerateAccessToken by the grantee -> a sensitive action as the impersonated service account, joined by principal + target + a time window
• Writing single-event rules (service-account key created T1098, primitive role granted, mass object read T1530, sensitive action from a new caller IP) and measuring their true positives and false positives against the same stream
• Reconstructing the full attack path/timeline from the correlated events, so the analyst receives one incident narrative rather than five disconnected alerts
• Feeling the number-one GCP detection failure first-hand: Data Access logs are OFF BY DEFAULT, so the exfil rule silently catches nothing until you enable them on the crown-jewel project
• Mapping each rule to a MITRE ATT&CK technique id, and knowing when a rule belongs in a streaming SIEM/Chronicle vs a scheduled BigQuery query

Steps in this lab

1. The question this engine answers: five alerts are not an incident
2. Set up: one folder, one file, no installs
3. Model the REAL Cloud Audit Log entry shape
4. Build the synthetic log stream: ~200 benign events plus honest noise
5. Plant the multi-stage attack: grant, impersonate, persist, exfiltrate
6. Small accessors on the real log shape
7. The headline rule: correlate the impersonation CHAIN
8. The supporting single-event rules, and why they are noisier
9. Run it with Data Access logging ON: the measured results
10. The failure mode nobody warns you about: Data Access logs are OFF by default
11. The judgment: where these rules live, and how to build them better
12. Contrast with the AWS CloudTrail detection lab, and why you must never ship this

Open the full interactive lab →