Navigation Reference

The homepage search spans detection rules and events/audit logs/record types. Use the filter dropdowns below the search bar (Type / Vendor / Tactic / More) for the most common filters, or type operators directly in the search box.

Shared behaviors#

Every operator takes the form name:value. These rules apply across the operators, so the tables below do not repeat them.

• Spaces AND. tactic:execution vendor:sigma returns rules matching both terms.
• Commas OR. The facet operators take a comma list of alternatives that OR together. Repeating a facet merges its values the same way, so vendor:sigma vendor:elastic equals vendor:sigma,elastic. The list operators (with:, uses:, excludes:, by: (alias groupby:), body:) instead AND across occurrences and treat a comma list inside one occurrence as an OR-group, for example, uses:Image,CommandLine matches a rule touching either field, while uses:Image uses:CommandLine requires both.
• Quotes force an exact match. In field: / value:, the quotes anchor the indicator match and allow spaces (value:"net user"). A quoted phrase matches exactly ("process creation").
• * is a wildcard inside a value, for example, value:*mimikatz*.

Negation#

Prefix a negatable operator with - to exclude its matches, for example tactic:execution -vendor:splunk. Negation stacks and refines a query. You can also pair it with a positive term. A - on a bare word (-foo) stays free text. A comma list under a negation excludes each alternative (-vendor:sigma,elastic drops both), and negation validates all-or-nothing. One invalid alternative keeps the whole token in free text instead of a partial exclusion.

Every operator negates, including the facet operators, the list operators, the indicator operators, and the semantic labels. An alias negates in the same bucket as its canonical form (-ta:execution is -tactic:execution). -type:rules returns every result kind except rules, -has:sample equals no:sample, -no:sample equals has:sample, and -like:slug drops the seed rule together with its equivalent, stricter, and broader relatives.

Standalone -kind: / -field: / -value: (with no positive field:, value:, or kind: in the query) exclude at rule level. They drop every rule carrying a matching predicate leaf, so type:rules -kind:is_null lists the rules that never null-check. Alongside a positive indicator filter they instead refine which leaves count as a match.

Search operators#

The tables share three columns. Operator is the token you type, with its alias in parentheses where one exists. Argument is what follows the colon. Effect is what the operator returns.

Scope#

MITRE ATT&CK#

Severity#

Rule structure#

Predicate fields#

These return rule cards and follow the list-operator comma rule above. Occurrences AND across the operator, and a comma list within one occurrence ORs.

Rule body#

body: is a deep full-text search over each rule's raw body/source text (the query as authored, including comments and syntax that never lands in the predicate tree), not just the parsed predicates that uses: / field: / value: search. Matching is exact-token, not substring. The index tokenizes on lowercased runs of 2+ alphanumeric or underscore characters, so body:mimikatz matches a rule whose body contains the standalone token mimikatz but not mimikatz2. The token index is a separate artifact that loads on the first body: query rather than shipping with the base search bundle.

Indicators#

The field: / value: / indicator: operators search detection-rule predicates, answering the question "has anyone written a rule for this IOC?" They drive two result kinds at once. The indicator tier shows one card per field+value pair, ranked by rule count. Each card shows the predicate kind, the total rule count with vendor breakdown, and the first 5 contributing rules. The card's +N more button expands the rest in place, so every contributing rule is one click away. The rule tier narrows rule cards to those carrying a predicate leaf that matches the filter (the card's matching-indicators line shows which leaf matched).

The two result kinds have different inclusion rules. The search returns a rule card when that rule has a matching predicate, even if no other rule uses the same field, predicate kind, and value. It returns an indicator card only when at least two rules use the same canonical field, predicate kind, and value, so indicator cards are not a complete list of every predicate or monitored value in the matching rules. When a rule appears without a corresponding indicator card, use its matching-predicates line or Show stages & exclusions to inspect that rule. To extract every distinct value selected by the complete query, use Copy matching values in the results toolbar.

kind: / field: / value: also narrow rule cards to those carrying a matching predicate leaf, ANDing with every other structural filter. For example vendor:elastic kind:cidr_match returns Elastic rules with a cidr_match leaf, and type:rules kind:is_null returns rules with an is_null leaf. They drive the indicator tier in parallel, and the card's matching-indicators line shows which leaf matched.

Curated semantic labels#

Four operators tag each rule by what its detection logic is about. They are the identity involved, the permission or access scope concerned, the resource inspected, and the operation performed. The site derives them from structured rule signals (parsed predicate fields, values, providers, platforms, and correlation keys), but the labels themselves are curated interpretations, not native IR properties. operation:public_exposure, for example, recognizes specific positive rule signals that indicate a resource was made public. There is no universal IR node named "public exposure."

Use these operators to discover related detection families across vendors, then validate a promising result with its matching predicates or a more direct field:, value:, kind:, or uses: query. A missing label does not prove the rule cannot detect the behavior, and a matching label does not make every rule interchangeable. A single rule commonly carries several labels. For example an LSASS-dump rule is resource:credential, and an Entra guest invite can be identity:external operation:account_lifecycle.

These operators filter rule cards only. Values are a closed vocabulary that autocomplete lists in full. A few curated aliases fold to the canonical value (spn → service_principal, guest → external, admin → admin_role, kms → crypto_key, secret → credential, pod → workload, login/signin → authentication, mfa → mfa_change).

Platform & domain#

Event attributes#

The "More" panel exposes six of these as three-way selects (any, yes, no) rather than checkboxes. Choosing yes writes has:<flag> into the query, no writes no:<flag>, and any removes the token. You can also type any event flag inline, including ones the panel does not expose.

Value reference#

The enumerated vocabularies referenced above. Each table pairs the canonical Value (with its alias in parentheses where one exists) with its Meaning.

Vendor values#

Used with vendor:.

Predicate kinds#

Used with kind:. The kind is the canonical predicate operator (how a rule matches a value), normalized across vendor lingo (kind:contains covers both Sigma's |contains modifier and Splunk's contains function).

For example value:10.0.0.0/8 kind:cidr_match, field:Image value:c:\windows\ kind:starts_with, field:CommandLine kind:regex, kind:in field:process_name.

is_null / is_not_null narrow rule cards and produce presence indicator cards. kind:is_null lists the fields the corpus null-checks (with rule counts and vendor breakdown). Because is_null / is_not_null carry no value, the card shows just the field and the kind. like is its own vendor-native kind (a SQL-style LIKE pattern, typed literally). It narrows rule cards, but the indicator tier does not carry it. The inverse holds for macro, length_compare, and func_call. They match indicator cards only, never rule cards, because the rule tier deliberately drops those leaf kinds as non-IoC structure. cross_field_compare is value-bearing but rare, and a field/kind/value combination used by only one rule does not produce an indicator card.

Identity values#

Used with identity:.

Permission values#

Used with permission:.

admin_role and application_role also include BloodHound Enterprise attack-path findings, which are computed posture ("a principal can reach that role"), not an observed grant.

Resource values#

Used with resource:.

credential also includes BloodHound Enterprise attack-path findings (LAPS/gMSA read, DCSync, Kerberoast), which are computed posture, not an observed access.

Operation values#

Used with operation:.

Event flags#

Used with has: / no:. has: requires the flag, and no: excludes it.

Flag values comma-split (has:sigma,threshold sets both) and validate all or nothing, so an unknown flag keeps the whole token in free text. With type:rules, the event flags return the rule set unfiltered and the status line says so (the flags describe events, which the rules scope never shows).

Free text & exact match#

Bare words (no operator) match event titles, fields, and descriptions, and, for rules, the title, description, and indexed predicate field/value tokens, so a keyword that lives only in a rule's logic still surfaces it. Quote a phrase for an exact multi-word match, for example "logon type" 4624 requires the exact phrase plus the free-text term.

Examples#

Result types#

Each result card carries a small label in the leading edge showing its type.

• EVENT is a Windows event log entry (provider / event ID / title)
• RULE is a detection rule (vendor badge + title + MITRE technique tags), with a vendor-colored left border
• PROVIDER is a Windows event provider with its event and sample counts
• INDICATOR is a field+value combination used by at least two rules, with the first 5 contributing rules below and a +N more button that expands the rest

A single query collects at most 200 rule cards and 100 indicator cards. The rule count shown on an indicator card is not capped (it reflects every contributing rule), so for an exact rule total on a query that hits the 200-card ceiling, either read the indicator card counts or split the query by vendor: and sum the results. Copy matching values is not limited by either card cap.

Working with results#

Each rule card has a Show stages & exclusions button that inlines the rule's stages, predicates, exclusions, and indicators in a scrollable panel beneath the card. It fetches the rule page once and caches per-rule for subsequent toggles. Useful for peeking at structural detail across several search hits without losing query context.

A Compact view / Expanded view toggle sits at the left of the toolbar above the cards. Compact view collapses every card to a single line for scanning large result sets. The choice persists across visits, and toggling writes a view= parameter into the URL hash so a copied link reproduces the same density.

The results toolbar provides Copy as markdown and Copy as JSON. Markdown export is a 12-column table (Type, Title, Vendor / Provider, Severity, Events, Technique IDs, Technique Names, Tactics, Author, Description (~2 sentences), Source (GitHub URL minus the host prefix), URL). JSON export is a flat array with the same 12 columns as snake_case keys (type, title, vendor_or_provider, severity, event_ids, technique_ids, technique_names, tactics, author, description, source_url, url). Every cell is a plain string, lists join with semicolons, and descriptions stay untruncated, so the output pastes straight into a JSON-to-CSV converter for spreadsheet use. Both cover every result in the current collected set, not just the visible page.

Predicate searches using field:, value:, indicator:, or kind: also provide Copy matching values. It copies one distinct, non-empty predicate value per line by reading every rule that satisfies the complete query. It includes values used by only one rule and ignores the 100-indicator and 200-total-card caps. For example, with:13 field:"TargetObject" copies every indexed TargetObject value from rules that bind event ID 13, even when no indicator card exists for that value.

• Click opens the result in the current tab
• Ctrl+click / Cmd+click / Shift+click / middle-click opens the result in a new tab

Keyboard shortcuts#

The site provides Vimium-style navigation.

Scrolling#

j and k to scroll down/up

d and u to scroll one-half page down/up

gg to scroll to the top

G to scroll to the bottom

Link hints#

f to show a single character per link that you can enter to open in the same tab

Searching#

/ to start a search. On a page with a search box it focuses the box. On a Windows catalog provider page it takes you to the /windows/ catalog search. On every other page it takes you to the combined event and rule search on the home page. The ?search= URL parameter that these redirects carry is presence-only, so any value (or none) focuses the search box on load.

Search results#

Arrow Down and Arrow Up to navigate results

Enter to open the highlighted result

Escape to close results

Navigation#

h to go back in page history

l to go forward in page history

Reading your query back#

A line under the search box explains the current query in plain language, for example "Rules binding event 4624 and also binding event 4769 but not from splunk." It updates on every keystroke and stays blank for an empty box.

When a value does not match its operator's vocabulary, for example sev:hi, the explanation adds a short warning and a clickable fix ("Did you mean severity:high?"). Clicking the fix corrects the query in place.

Focusing an empty search box opens a starter panel with your recent searches at the top and curated example questions grouped under four headings ("What events exist", "How the rule is built", "What the rule is about", "What the rule looks for"). Clicking a question runs its query. Escape closes the panel.

A rule page carries the same idea in its Indicators and Exclusions tables. Each row gets a Search column that runs the matching query back on the home search, so you can pivot from one rule's predicate straight into every other rule that shares it.

The curated identity, permission, resource, and operation labels above have their own reference page at /references/semantic-labels/, with every value's meaning and how many rules carry it.