| name | log-triage |
| description | Identity-log triage workflow — anomaly patterns per provider (AWS CloudTrail, Azure AD/Entra, Google Workspace, Okta), session and token misuse, MFA-bypass signals, conditional-access evasion, and cross-provider correlation. Produces a prioritized finding list routed to ir-runbook or detection-engineer. |
Log Triage
Identity-first context: the bulk of modern incidents starts or escalates via identity providers. Logs are the truth source — UIs are stale snapshots. This skill covers audit/identity logs from the major IdPs; network logs and endpoint EDR touch on this but live in other skills.
When to use
A log-triage question begins with "something is odd in the logs, take a look". This skill provides, per provider, the pattern set you can use to triage where people get lost in volume.
Triggers on:
- A question like "look at these CloudTrail events", "is this Azure AD sign-in anomaly real", "Google Workspace audit log has N login failures", "what is the anomaly here in Okta", "compromised-account investigation".
- A handoff from
detection-engineer (rule fired, asks for deeper triage), ir-runbook (incident investigation), ioc-hunter (IOC match in an identity log).
- A proactive hunting session focused on identity anomalies — overlap with
threat-hunt.
- A post-incident investigation where the identity path must be reconstructed for
forensics-assist or regulatory reporting.
When NOT (handoff)
- Generic SIEM-query building →
siem-query.
- Writing a detection rule based on the pattern →
detection-engineer.
- A threat-hunt session as a whole →
threat-hunt (command).
- Forensic memory/disk analysis →
forensics-assist.
- Network-flow triage or EDR process events → out of scope here; covered in generic SIEM-query or an EDR-tool skill.
- IOC curation or enrichment →
ioc-hunter.
- Regulatory reporting →
ir-runbook plus nis2/gdpr-pia.
Approach
Six phases. Phase 1 (provider context) and phase 4 (cross-provider correlation) are where triage builds from isolated events into a meaningful path.
1. Provider context and log-source inventory
Identity logs differ per provider in event shape, retention, and accessibility. Triage starts with "which provider, which log stream, which retention".
- AWS: CloudTrail (management + data events), CloudTrail Insights (anomaly detection, paid), GuardDuty (managed detection, IAM-relevant findings).
- Azure / Entra ID: Sign-in logs (interactive + non-interactive + service-principal), Audit logs (directory changes), Risk Detections (Identity Protection), Provisioning logs.
- Google Workspace: Login audit, Admin audit, OAuth Token audit, Drive audit.
- Okta: System Log (all auth events plus admin actions), Tableau Insights (managed anomaly).
- JumpCloud / OneLogin / Ping: comparable structure.
- On-prem AD: Security Event Log via Sysmon/Windows Audit; via DC SIEM forwarder.
Per source: retention window (default often shorter than the compliance requirement), log completeness (are all event types enabled?), log integrity (forwarding to SIEM complete?).
Pre-triage check: do you have access to all relevant streams for the time window of the incident, not just the "obvious" stream?
2. Anomaly patterns per provider
Per IdP, a pattern set you walk through by default. Not exhaustive; a starting point for triage.
AWS CloudTrail:
- Console login without MFA where policy requires MFA. Event:
ConsoleLogin with additionalEventData.MFAUsed=No.
- GetSecretValue / Decrypt bursts by one principal in a short window — credential-harvesting pattern.
- AssumeRole-cross-account from an unexpected source account.
- CreateAccessKey + persist for an existing user (pattern T1098.001 — additional cloud credentials).
- DisableLogging events: StopLogging on Trails, DeleteTrail, UpdateConfigurationRecorder. Pattern T1562.008.
- Mass S3 GetObject or
ListBuckets over a short window — exfil discovery.
- IAM policy with
Resource: "*" plus Action: "*" — overly permissive setup.
- Region anomaly: activity in regions the org never deploys to.
Azure AD / Entra ID:
- Sign-in from impossible travel: geo-pattern with velocity > realistic flight time. Identity Protection flags this, but verify in detail (VPN effects, mobile roaming).
- MFA-fatigue pattern: multiple MFA prompts in quick succession followed by an approve. T1621 pattern. Conditional Access can block this with "request-frequency limit".
- Service-principal misuse: a principal with an admin role suddenly signing in from non-authorized locations.
- Legacy auth-protocol use: Basic Authentication, IMAP, POP — usually MFA-bypassing. Should be off.
- Conditional-Access bypass attempts: failures on a CA policy followed by success via another route.
- Application consent grants with sensitive scopes (Mail.ReadWrite, Files.ReadWrite.All) by regular users — illicit consent grant T1528.
- Token replay: same token from different locations.
Google Workspace:
- OAuth grants with external apps by regular users — Drive-data-leak vector.
- Admin-Add / Role-Change: privilege elevation.
- Mass mail-forward-rule set: BEC classifier T1114.003.
- Login from unusual location plus device-fingerprint mismatch.
- 2SV disabled for an account that previously had 2SV — recovery or abuse.
- Drive scope-share "anyone with link" on sensitive data.
Okta:
- Push-notification reject followed by push-accept elsewhere — MFA fatigue.
- Factor reset by an admin on a user — backdoor pattern.
- API-token creation by an admin with a high scope.
- App-instance-add / OIN-app grant with a high scope.
- Bypass of network-zone policies.
3. Per-event triage: question row
For each suspicious event, answer:
- Actor: user, service account, or API token? Was the behavior expected for this actor?
- Source: IP, ASN, geographic, device fingerprint. Match this against known employee locations / mobile providers / VPN exit points / cloud-provider IP ranges.
- Authentication chain: how did the actor sign in (password, certificate, SAML assertion, OAuth token replay)? MFA used? Which factor?
- Time: within working hours for this actor? Coherent with other activity (before/after)?
- Outcome: success, failure, partial. On failure: what is the exact error? Which control caught it?
- Prior behavior: what did this actor do 24h before? Pattern shift?
Collect answers in incident-table form. Without structure you lose consistency across events.
4. Cross-provider correlation
Real attacks spread across identity providers. A disturbance in Azure AD often propagates into AWS via federated auth, into Google Workspace via SAML, into SaaS tools via OAuth.
Correlation strategies:
- User-identity mapping: the same person in Azure AD + Google + Okta + AWS. Email match works often. Document the mapping in advance so triage does not become a lookup loop.
- Time-window overlap: actor X active in Azure AND a GuardDuty finding in AWS in the same 30-minute window.
- IP correlation: the same IP for a sign-in in two providers within a short window.
- Token-trail tracking: a SAML assertion from IdP A produces an AccessKey on cloud B that is used to hit SaaS resource C.
SIEM tooling with cross-provider data is critical here (see siem-query). Manual correlation works for small investigations; for larger incidents, a unified data layer is needed.
5. Prioritization and triage output
Per finding:
-
Severity classification:
- Confirmed compromise: evidence of real misuse, route directly to
ir-runbook.
- High-suspicion: pattern matches, no direct evidence, asks for deeper action (force MFA reset, verify with user).
- Anomalous but explainable: looks anomalous but matches a legitimate situation. Document for the baseline.
- Background noise: false-positive pattern. Handoff to
alert-tuning for rule adjustment.
-
Recommended action per finding: account disable, force pw reset, MFA re-enroll, key rotation, conditional-access tighten, deeper forensics.
-
Handoffs: high-suspicion and confirmed → ir-runbook; pattern feedback → detection-engineer; new IOCs → ioc-hunter; tuning input → alert-tuning.
6. Verification-loop
Layer 1: scope (all relevant streams checked for the time window, no blind spots like service-principal logs or OAuth-grant logs?), assumptions (user confirmed or denied the activity?), gaps (cross-provider correlation done, not just single-provider tunnel vision?). Layer 2: event-type names match current provider docs, no invented field names or API event IDs, ATT&CK T-IDs correct.
Output
Log triage — <scope / actor / event-cluster>
Time window: <start → end UTC>
Streams checked: <provider × log source>
Findings (per actor, per provider):
Actor: <user-ID + provider>
Provider: <AWS/Azure/Google/Okta>
Pattern: <impossible-travel / mfa-fatigue / illicit-consent / etc>
Events: <event IDs + timestamps>
Severity: <confirmed | high-suspicion | anomalous-explainable | noise>
Cross-provider correlation:
IP overlap: <IP found in providers X, Y>
Time overlap: <actor cluster within N minutes>
Token trail: <if relevant>
Recommended actions per finding:
- <actor>: <account-disable / force-pw / MFA-reset / key-rotate / etc>
Handoffs:
ir-runbook: <confirmed compromises>
detection-engineer: <pattern supports a new rule>
ioc-hunter: <new IOCs for enrichment>
alert-tuning: <noise rules for lifecycle treatment>
Verification-loop: ...
References
Categories
