Cat Scanv1.6.31
Search Windows Event IDs by number, keyword, log, or audit category — with how‑to‑collect steps.
No matches in any reference table.
Seen in the Error Code field of Event ID 4776.
Seen in the Result Code field of Kerberos ticket events 4768, 4769, 4770, 4771, 4772, 4774, 4775, 4777, 4820, 4821, and 4824.
Seen in the Ticket Encryption Type field of Kerberos ticket events 4768, 4769, 4770, 4771, 4772, 4774, 4775, and 4777.
Seen in the Pre-Authentication Type field of Kerberos ticket events 4768, 4769, 4770, 4771, 4772, 4774, 4775, 4777, and 4824.
Bit flags making up the Ticket Options field of Kerberos ticket events 4768, 4769, 4770, 4771, 4772, 4774, 4775, 4777, 4820, and 4821 — OR the relevant bit masks together to decode a value (e.g. 0x40810010 = forwardable + renewable + canonicalize + renewable-ok).
Seen in the Logon Type field of logon-related Security events (4624, 4625, 4634, 4647, 4648, 4649, 4675, 4779, 4800–4803, 4964, 5378, 5632, 5633).
Seen in the Protocol field of IPsec and Windows Firewall events (4709–4712, 4944–4958, 5031, 5040–5048, 5140, 5150–5159, and the 5440–5477 range) — 67 events in total.
Seen in the Reason Code field of Network Policy Server events 6272–6280.
Seen in Event ID 40 (TerminalServices‑LocalSessionManager).
Raw Group Policy audit category mapping, before expansion into individual events.
1,417 technique–event associations across 390 ATT&CK techniques and 48 Security-log events. High-fan-out events (e.g. 4688 Process Creation maps to 286 techniques) are truncated in the main catalogue's detail view — this is the full table. Search by technique ID, technique name, or event ID.
1,795 official Windows NTSTATUS values (code, symbolic name, and description) — the full range returned in fields like Status / Sub Status on events such as 4625 (An account failed to log on). Search by code or name.
Message-table string references (the raw %%NNNN tokens Windows substitutes into rendered event text) seen in two places: the Sub Status field of Event ID 4625 (An account failed to log on), and the Logon Process / Authentication Package fields of logon-related Security events.
The Splunk Common Information Model data models/datasets that a Windows event log maps cleanly to, for normalizing this catalogue's events alongside other vendors' data in Splunk. The TA-Verified column shows whether that dataset is confirmed by the real Splunk Add-on for Microsoft Windows package (v11.0.2)'s own eventtypes.conf / tags.conf — "Yes"/"Partial" rows are cross-checked against the actual product; "No" rows are this catalogue's own analysis for sources the add-on doesn't cover at the event-code level (Sysmon, Terminal Services, the dedicated Windows Firewall channels, Certificate Services Client, and more). Populated on events only where the mapping is well-established and unambiguous — a blank "Splunk CIM" field means no confident single-dataset mapping exists.
Search, filter and browse every field parsed out of an event's sample log text — only events with a detailed field schema (beyond the common header envelope) appear here.
| Log | Event | Field | Type | Category |
|---|
Cross-tabulate the catalogue by any two facets — log, category, ACSC priority, MITRE technique, NIST 800-53 AU control, and more — then click a cell, row, or column to see exactly which events fall into it.
Every operation across six Microsoft cloud audit/log schemas — Microsoft Entra ID, Azure resource logs, the Azure Activity Log, Microsoft Intune, Microsoft Purview's unified audit log, and Azure DevOps — mapped to its category, resource provider, and resource type.
| Service | Category | Operation | Resource provider | Resource type |
|---|
Action Explorer — every AWS IAM action, mapped to its CloudTrail event where one exists and to ACSC (Australian Cyber Security Centre) logging guidance where AWS/ACSC recommend logging it. Loaded from a JSON export of Events_Other/aws_iam_actions_expanded.csv, fetched at runtime rather than embedded in the page — like Threat Detection’s Heat Coverage tab, this needs the page served over http(s), not opened directly as a file.
| Service | Action | Description | CloudTrail | ACSC |
|---|
Search Linux security & system events by ID, keyword, log, or audit category — with how‑to‑collect steps.
Every field name that can appear in a kernel audit record (SYSCALL, PATH, EXECVE, AVC, USER_*, and the rest) — name, value format, and what it means. auid is the one to trust for "who did this," even after su/sudo; decode hex/encoded fields with ausearch -i. Enriched with each field's nearest Splunk CIM (Common Information Model) equivalent — potential CIM name, whether that field is actually CIM-supported, which data model(s) it falls under, and which Splunk app/TA maps it out of the box vs. needing a custom FIELDALIAS/EVAL — where a mapping was known; scroll the table right to see it. "—" means no known CIM mapping; a blank cell means this field wasn't covered by the CIM enrichment pass at all.
Every value the type= field can take at the start of a record in /var/log/audit/audit.log. An event is one or more records sharing the same timestamp + serial number — the most common multi-record event is SYSCALL + PATH (×N) + CWD + EXECVE / PROCTITLE.
The core auditd tools and their most useful options — search matches a command name, an option (e.g. -k, --start today), or a section title.
Full manual pages for the auditd command family — auditctl(8), ausearch(8), aureport(8), auditd(8), augenrules(8), autrace(8), and audispd (merged into auditd since audit 3.0 — see its entry for what replaced it). Search matches a command name, a section heading, or any text inside a section.
The default rule files shipped with fapolicyd (/etc/fapolicyd/rules.d/), transcribed verbatim from upstream. Rules are evaluated in filename order — first subject+object match wins.
The subject and object attribute keywords usable on either side of a fapolicyd rule's : — from fapolicyd.rules(5). Used in shows whether a field applies to the subject (the process), the object (the file), or both.
The decision keyword that opens every rule, and the perm= values that follow it.
The core fapolicyd tools and their most useful options — search matches a command name, an option, or a section title.
Full manual pages for the fapolicyd command and config family — fapolicyd(8), fapolicyd-cli(8), fagenrules(8) (the fapolicyd counterpart of auditd's augenrules(8)), fapolicyd.conf(5), and fapolicyd.rules(5). Search matches a command name, a section heading, or any text inside a section.
Guides for capturing user command activity (shell history, not just what auditd's own syscall rules see) and getting it to a SIEM in real time — a distinct topic from the Linux Audit Framework covered under Auditd Rules, though the stronger of these guides' own recommended approaches uses auditd as one layer.
Where RHEL, IdM/FreeIPA, and other common add-on services actually write their logs — plain files, directories of per-component logs, binary accounting files best read with a dedicated tool, and services that log only through journalctl with no flat file at all (the Type column says which). Repo owner-supplied; not tied to any event in this catalogue's main list. Click a column header to sort.
No matches in any reference table.
The type= field of every kernel audit record — verified against include/uapi/linux/audit.h in the upstream Linux kernel source. This is the field that doubles as this catalogue's Event ID for every audit/* log.
Return codes from Linux-PAM's _pam_types.h — seen (as a name, not the raw number) in the res= field of USER_AUTH, USER_ACCT, and USER_ERR records.
A curated 27-capability subset (of 41 total) of the CAP_* bits from include/uapi/linux/capability.h — each is one bit position in the cap_pe/cap_pp/cap_pi hex masks of a CAPSET record (event ID 1322).
A curated set of the standard Linux errno.h values — seen (negated) in the exit= field of a failed SYSCALL record (event ID 1300).
The 15 SSH_DISCONNECT_* reason codes from RFC 4253 §11.1 — sshd prints the raw number in its "Received disconnect from ⋯" syslog line, and this catalogue uses that number as the Event ID for the ssh/protocol log.
Real MESSAGE_ID UUIDs from systemd's own catalog (catalog/systemd.catalog.in upstream) — the closest Linux analogue to a numeric Windows Event ID for anything that isn't routed through the kernel audit subsystem.
Technique–event associations for the events in this catalogue. Search by technique ID, technique name, or event ID.
Australian Cyber Security Centre Information Security Manual controls whose xccdf_org.ssgproject.content_profile_ism_o SCAP profile rules correspond to events in this catalogue — sourced from controls/ism_o.yml in ComplianceAsCode/content, the project behind that profile. Mapped at the subcategory level (like this catalogue's NIST 800-53 mapping); see the README for where this catalogue's event mechanism and the profile's underlying rule mechanism diverge even though both serve the same control.
Every subcategory's config path, steps, event IDs, and NIST 800-53 AU mapping — the same data shown inline on each event's detail view, browsable as one table. See also docs/audit-configuration-guide.md.
Other tools by the same author — not part of this repo's own data, just useful alongside it.
Every technique in the Enterprise ATT&CK matrix, shaded by how many of this library's detections — summed across all fourteen catalogues and every platform, not just one — actually map to it. Dashed cells are gaps: zero detections reference that technique today. Sub-techniques roll up into their parent (T1098.001/.002/… all count toward T1098) — hover or focus a cell for the breakdown.
How many of this library's own required_log_source references line up with one of Microsoft Events' own 197 log channels — a narrow, exact/aliased-match pass against Microsoft Events only, not Linux/AWS/Other Events, so a source listed as unmatched below may still be catalogued elsewhere in this compendium (Dell iDRAC and HPE OneView, for instance, are Other Events vendors) — it just wasn't checked against them in this pass. Matched log channels show their own detection count as a badge in Microsoft Events' own Log filter.
Most-referenced sources with no Microsoft Events match in this pass:
A validation catalogue is not a detection catalogue: each entry below is a test-execution reference for confirming an existing detection actually fires, not a production rule of its own — the exact command to generate one privileged action (RHEL, FortiGate, Cisco SD-WAN, RHEL IdM/IPA, or Windows — see the Platform filter), whether it's safe to run in a lab (SAFE Test), a rollback step, expected platform telemetry, and a one-shot presence-check search. See docs/validations.md for the full rationale.
Raw vendor catalogue data, not detection content of this library's own writing, pulled verbatim from each platform's own reference: every Active finding type AWS GuardDuty can currently generate, as published on AWS's own GuardDuty active finding types reference page — finding type, affected resource, the foundational data source/feature that has to be enabled to generate it, AWS's own severity rating, and AWS's summary, detailed description and remediation guidance verbatim — and every analytics rule in Microsoft Sentinel's own analytics-rule catalogue, including its MITRE ATT&CK tactics/techniques, required connectors and data types, query cadence and trigger condition, and full KQL query. Filter by Platform (the native-detection source, so platforms can share this page), Threat Purpose (for GuardDuty, the prefix before the colon in the finding type; for Sentinel, the rule's primary MITRE ATT&CK tactic), Resource Type (GuardDuty's affected resource, or Sentinel's primary entity type), Severity, or Foundational Data Source.
