Searching with KQL

Why it matters

Most answers in an investigation are not printed on the alert. An account, a host, a destination, when it started: you find them by asking the SIEM a precise question and reading what comes back. Scrolling an unfiltered list of events finds them by luck.

Search is also how you test an idea cheaply. "Did this account sign in anywhere else?" is one query and a few seconds, not an hour of reading.

What analysts see

In Elastic Security, most searching happens in Discover, the screen you open first:

• A query bar that takes KQL (Kibana Query Language), with a time picker beside it.
• A results table of matching events, each one expandable to every field it contains.
• A field list down the side. Click a field to see its top values in the current results, without writing a query.
• Filter pills above the results: conditions pinned in place, separate from the query bar, that stay put while you change the query.

Discover is where you search. When findings start adding up, Elastic Security's Timeline is where you build the investigation: add events to it from Discover, keep notes beside them, and query within it using KQL or ES|QL. Your First Investigation walks through it.

Core concept

A KQL query is a set of conditions written as field: value. Combine them with and, or and not, group them with parentheses, and the results are every event in the time range that meets them.

Two details decide most results. The time range is part of every query even though it is not in the query bar: a correct query over the wrong window returns nothing, and Discover opens on a recent window by default. And fields such as account names, hosts and addresses compare the whole value, so quote it exactly; a * wildcard works only outside quotes.

Beyond field: value: field: * asks whether a field is present at all, ranges such as source.bytes >= 1000000 compare numbers, and a leading wildcard such as url.domain: *.sync-cdn.example matches every name under a domain.

Annotated examples

How to investigate

1. 1.

   Set the time range first.

   Start wider than you think the activity lasted, confirm there are events at all, then shorten it.

2. 2.

   Ask one question and read the count.

   One condition at a time. The count and the top values in the field list tell you whether to add a condition or widen next.

   user.name: "d.pryor"

3. 3.

   Subtract what you understand.

   Use not to remove the expected, then read what is left.

   user.name: "d.pryor" and not host.name: "ws-310.corp.example"

4. 4.

   Pivot on a value you found.

   Take a value from a result, such as a host, an address or a file path, and make it the next query, or pin it as a filter.

   process.executable: C\:\\Users\\Public\\*

5. 5.

   Keep the queries that answered something.

   Save them, or copy them into your notes with their time range: a query without its window cannot be run again to the same answer.

Common mistakes

• Mistake: Deciding the query is wrong because it returned nothing.

  InsteadCheck the time range and the field name first. A field that does not exist in these events matches nothing, silently.

• Mistake: Putting a wildcard inside quotes.

  InsteadInside quotes, * is a literal asterisk. Leave wildcards unquoted and escape special characters (:, \, spaces) with a backslash.

• Mistake: Searching for part of an account, host or address.

  InsteadThese fields compare whole values. Use a wildcard for "starts with", or the field list to see the exact spelling.

• Mistake: Retyping the same condition into every query.

  InsteadPin it as a filter once, then change only the question.

• Mistake: Reading thousands of results one by one.

  InsteadAdd conditions until the results are few enough to read, or read the top values instead.

Field references

Check yourself

1. 1.
   Your query is correct, but it returns no events. What do you check first?

   • A.Whether to add a wildcard
   • B.Whether to remove the quotes
   • C.The time range
   • D.Nothing: the activity didn't happen

2. 2.
   You want events for the account a.halloran and no other. Which query?

   • A.user.name: a.halloran*
   • B.user.name: "a.halloran"
   • C.user.name: "a.halloran*"
   • D.a.halloran

3. 3.
   Which query returns events for both accounts, excluding their usual host?

   • A.user.name: "a.halloran" or user.name: "m.castell" and not host.name: "ws-120.corp.example"
   • B.user.name: "a.halloran" and user.name: "m.castell" and not host.name: "ws-120.corp.example"
   • C.user.name: ("a.halloran" or "m.castell") and not host.name: "ws-120.corp.example"

4. 4.
   Which query matches every subdomain of files-cdn.example?

   • A.url.domain: "*.files-cdn.example"
   • B.url.domain: *.files-cdn.example
   • C.url.domain: "files-cdn.example"

5. 5.
   You've found one event worth a closer look on ws-120.corp.example. What's the most useful next step?

   • A.Widen the time range to the whole year
   • B.Retype the host into every new query by hand
   • C.Stop: one event is enough to conclude
   • D.Pin the host as a filter, then ask the next question

Apply it in a Case

Pick a case, and before you open a single event, write down three questions its briefing raises. Answer each with one query, and note the count it returned.

• CuckooSkills: SIEM search · Log analysisTelemetry: Windows · Sysmon
• GhostwriterSkills: SIEM search · Log analysisTelemetry: Windows · Sysmon
• DragnetSkills: SIEM searchTelemetry: Network

References

• Kibana Query Language (KQL) · Elastic
• Discover · Elastic
• Timeline · Elastic Security
• ES|QL · Elastic
• ECS field reference · Elastic