Audit Log Explainer
Paste one CloudTrail, Okta, Google Workspace or Slack audit event. Read who did what, from where, whether it worked, the risk, the next queries to run, ATT&CK techniques and the SigmaHQ rules that fire.
The event stays in this tab. A whole export works too: the first record is explained.
| Event | Source | Access | Severity | ATT&CK | SigmaHQ |
|---|
How the explainer reads an event
The page recognises the source from its shape: eventName and eventSource for CloudTrail, eventType and actor for Okta, id.applicationName and events for the Workspace Reports API, action and context for Slack. It then decodes the fields an analyst checks first.
- Who. For CloudTrail the full principal chain: userIdentity.type, the role session and its issuer, sourceIdentity, MFA on the session, IAM Identity Center permission sets, EC2 instance profiles and IMDS version, web identity providers such as GitHub Actions, and what the access key prefix means (AKIA long-term, ASIA temporary). For Okta the actor, session ID, transaction and targets.
- From where. Source IP and its range, Okta geolocation and network, and the client from the user agent: console, AWS CLI (with the command it ran), each AWS SDK, Terraform, scripts, and tooling such as TruffleHog or a Kali Linux build.
- What kind of access. Read, write, delete or sign-in, and the outcome with what the error code means.
- What to do next. A risk note, common benign causes, triage steps and ready-made queries for CloudTrail Event history, CloudTrail Lake, the Okta System Log API, the Reports API and the Slack Audit Logs API, filled with the IDs from the event.
- Detections. ATT&CK techniques commonly tied to the event, the SigmaHQ rules that fire on it, and a draft Sigma rule you can test or refine.
Audit log explainer FAQ
Is the event uploaded anywhere?
No. The event is decoded by JavaScript on this page. The page downloads one data file from pwnsy.com with the SigmaHQ rules and vendor references, and nothing you paste leaves the browser.
What is the difference between an AKIA and an ASIA access key?
AKIA is the prefix of a long-term access key that belongs to an IAM user or the root user and works until it is deleted. ASIA is the prefix of a temporary key issued by AWS STS, for example by AssumeRole or GetSessionToken, and it stops working when its session expires.
How do I find the person behind an AssumedRole session in CloudTrail?
Read userIdentity.sessionContext.sessionIssuer for the role, the last part of userIdentity.arn for the session name, and sourceIdentity if it is set, since it carries the original identity through role chaining. Then search for the AssumeRole event whose responseElements.credentials.accessKeyId equals the session's accessKeyId to see who assumed the role. For IAM Identity Center roles named AWSReservedSSO_, the session name is normally the user's Identity Center user name.
Which events does the page know?
The catalog holds 145 high-signal events: 72 CloudTrail API and sign-in events, 29 Okta System Log event types, 27 Google Workspace Reports API events and 17 Slack audit actions. Each name was checked against the vendor's own reference. Any other event from these four sources still gets a generic decode of who, where, access type and outcome.
How are the SigmaHQ rules matched?
The page holds the 88 SigmaHQ CloudTrail, Okta and Google Workspace rules from one pinned commit. It runs every rule for the event's source with the same Sigma engine as the Sigma Rule Tester and lists the ones that fire, plus the rules that reference the event name. SigmaHQ has no Slack audit log rules, so for Slack the page drafts one.
Event names checked in October 2026 against botocore service models and the AWS CloudTrail and Amazon S3 user guides, the Okta event types catalog, the Admin SDK Reports API activity reference and the Slack Audit Logs API reference. ATT&CK v19.2. SigmaHQ rules under the Detection Rule License 1.1. Sample events are made up and use documentation IP ranges.