Audit Log Explainer
Paste one audit event. Read who did what, the risk and the next queries.
| Record | Event ID | Channel | Card | Severity |
|---|
| Event | Source | Access | Severity | ATT&CK | SigmaHQ |
|---|
The event stays in this tab. A whole export works too: the first record is explained. An .evtx file is read in the page and listed by record.
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, and EventID with its channel or provider for Windows and Sysmon (an .evtx file, XML, Winlogbeat or flat JSON). An .evtx file is decoded in the page from its Binary XML, the way Event Viewer renders it, and each record can be explained in turn. 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. For Windows the subject and target accounts, well-known SIDs and privileged groups, and the logon ID that ties a session together.
- 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. For Windows the source address, workstation and host, the logon type, the authentication package, and the process.
- What kind of access. Read, write, delete, sign-in, execute or network, and the outcome with what the error code means: NTSTATUS codes in 4625 and 4776, Kerberos result codes in 4768, 4769 and 4771. Outside the Security log the catalog reads System service and log events, PowerShell script block, module and pipeline logging, Defender Antivirus detections and configuration changes, Remote Desktop, Task Scheduler, WMI and BITS, and each card checks the channel so an ID from another log never borrows it.
- Decoded fields. Logon types, ticket encryption and pre-authentication types, token elevation, service types, account flags, Sysmon GrantedAccess rights (an lsass.exe read is flagged), scheduled task commands and encoded PowerShell, each from the Microsoft page that defines it.
- 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, the Slack Audit Logs API, Get-WinEvent, Microsoft Sentinel and Defender advanced hunting, 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.
Accuracy and how it compares
Measured on 6 November 2026 with the code this page runs, on the hayabusa-sample-evtx set (commit 0845333): 599 .evtx files and 47,699 records from EVTX-ATTACK-SAMPLES (4ceed2f), DeepBlueCLI, EVTX-to-MITRE-Attack and Yamato Security captures.
| Measure | This page | Reference |
|---|---|---|
| Records read from the 599 files | 47,699, none failed | python-evtx 0.8.1 reads 46,018. It stops on 15 EVTX 3.2 files whose elements omit the dependency identifier. |
| Agreement with python-evtx, System fields and every Data and UserData value | 45,692 of 46,018 identical (99.3%) | The other 326 are string arrays. python-evtx splits the same text differently in 257 and drops or repeats leading empty items in 69 (checked by hand: System 6013 needs seven insertion strings, python-evtx returns four). |
| Records with a curated card | 36,315 of 47,699 (76.1%), up from 22,475 (47.1%) | The rest get a generic decode of who, where and outcome. |
| Hayabusa summary events (config/default_details.txt, hayabusa-rules 9a1b0f5) | 70 of 102 covered, up from 34 | Hayabusa writes a one-line summary for these 102 provider and event ID pairs. |
| Hayabusa rule references whose channel and event ID have a card | 95.5% of 5,171, up from 85.3% | 5,021 Hayabusa and converted Sigma rules at 9a1b0f5. |
| Code decodes: Status, SubStatus, LogonType, GrantedAccess, ticket encryption, pre-authentication, token elevation, service type | 22,338 values in the corpus; every numeric code matched its Microsoft table | 339 stay raw: 7045 service types that are already words, and status numbers outside the Security log. |
| Read speed | 139 MB in 1.7 s (84 MB/s, Node 20 on a laptop) | Browsers run the same code; a 10 MB Security log with 13,223 records takes well under a second. |
The run found one bug, now fixed: 38 Application log records with event ID 4625 were explained as Security failed logons. Every Windows card now checks the channel.
Known limits: one event is explained at a time. Hayabusa and Chainsaw run thousands of Sigma rules across whole files and build a timeline; here the SigmaHQ rules run on the selected record. 32 of Hayabusa's 102 summary events still get a generic decode (Print Service, MSI Installer, Windows Firewall 2003 and 2004, DNS Server, Exchange cmdlet logs, Defender 1013, and Security 4765, 5379 and 4692). Like python-evtx and evtx_dump, the reader shows the event XML without the provider's message text. Files over 150 MB need filtering with wevtutil or Get-WinEvent first. Field names for some events outside the Security log come from sample logs, because Microsoft does not publish them.
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 Windows log formats work?
An .evtx file as Windows writes it (up to 150 MB), read in the page and listed by record; the XML of one event, as Event Viewer, wevtutil or Get-WinEvent ToXml() show it; Winlogbeat or Elastic Agent JSON with winlog.event_id and winlog.event_data; and flat JSON with EventID and EventData, as NXLog or a Sentinel SecurityEvent row gives it. The channel or provider tells Security, other Windows logs and Sysmon apart. Get-WinEvent JSON drops the field names, so export XML instead.
How does the page spot Kerberoasting in event 4769?
It reads TicketEncryptionType. Microsoft lists 0x17 as RC4-HMAC and 0x12 as AES256. An RC4 service ticket for a service that is not a computer account, which ends in $, is the request pattern of Kerberoasting tools, so the page raises the severity and gives a query that counts how many services the account asked for. Event 4768 with pre-authentication type 0 gets the same treatment for AS-REP roasting.
Which events does the page know?
The catalog holds 248 high-signal events: 72 CloudTrail API and sign-in events, 29 Okta System Log event types, 27 Google Workspace Reports API events, 17 Slack audit actions, 56 Windows Security event IDs, 20 events from other Windows logs (System, PowerShell, Defender Antivirus, Remote Desktop, Task Scheduler, WMI and BITS) and 27 Sysmon event IDs. Each name was checked against the vendor's own reference, Windows events that Microsoft does not document on Learn against the Hayabusa rule set, and the Windows decoding tables against the Microsoft pages they come from. Any other event from these 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, plus 145 Windows Security rules and 683 Sysmon category rules that load when you paste a Windows event. 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 or ID. Sysmon category rules carry no event ID, so the page picks them with the pySigma Sysmon category map. The 1,190 process creation rules run in the Sigma Rule Tester. 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. Windows event IDs and decoding tables checked in November 2026 against the Microsoft Learn audit event pages, the Windows Event Forwarding, PowerShell logging and Defender Antivirus event pages, the Active Directory control access rights pages, MS-ERREF, MS-SAMR, the Sysmon page and the Sysmon manifest, and Hayabusa rules for the rest. ATT&CK v19.2. SigmaHQ rules under the Detection Rule License 1.1. Sample events are made up and use documentation IP ranges.