Skip to content
Sign In
Learn

Learn · Telemetry

Reading the Telemetry

Read an event field by field until the format stops looking like noise and starts answering questions.

About 10 min

In this unit
How to read a raw event field by field, and which fields to trust.
Not yet read in this browserSign in to see where you have applied this.

Why it matters

Every question in an investigation is answered by a field in an event. Knowing that Sysmon logs process creation, or that Zeek logs DNS, tells you where evidence can exist. It does not tell you what the evidence says. Reading an event well is the difference between scrolling past the signal and stopping on it.

The skill transfers. Once you can read five event shapes, most new ones are variations on questions you already know how to ask.

What analysts see

In a SIEM such as Elastic, every event arrives as a flat list of fields and values. One intrusion leaves traces in several shapes at once:

  • Windows Security events: authentication and account activity, each identified by an event code.
  • Sysmon events: process, file and registry activity on Windows hosts, with parent and child processes linked. Sysmon is now a built-in optional feature of Windows 11 and Windows Server 2025, but it is off by default: someone still has to enable and configure it before it records any events.
  • Linux audit events (auditd): process execution and file access recorded by the kernel.
  • Zeek logs: passive network metadata such as name lookups and connections. Nothing in them says which process or user was responsible.
  • Suricata alerts: signature matches on network traffic, with a severity.

The field names differ between these families, and a field from one family simply does not exist in another. Knowing which family an event belongs to is the first thing to settle.

Core concept

Every event answers the same four questions, in the same order: what happened (the event type), who or what did it (a user, a process, a host), how it relates to what came just before (a parent process, a preceding request), and whether it fits the normal pattern for that account or host.

The event type comes first because it decides what every other field means. In a Kerberos service ticket request, TargetUserName is the account the ticket is for; when someone signs in, the same field is the account that signed in. Read the code, then the fields.

Annotated examples

A Windows Security event

Event 4769, "A Kerberos service ticket was requested," as it lands in Elastic:

event.code:
"4769" (note 1)
winlog.event_data.TargetUserName:
"svc_reporting" (note 2)
winlog.event_data.ServiceName:
"svc_reporting"
winlog.event_data.TicketEncryptionType:
"0x17" (note 3)
winlog.event_data.IpAddress:
"192.0.2.24" (note 4)
  1. Note 1: The event code decides what the rest means: 4769 is a service ticket request.
  2. Note 2: The account the ticket is for. Both fields naming the same account is specific to ticket requests, not universal.
  3. Note 3: 0x17 is RC4, the older encryption type that can be cracked offline. For this event it is the strongest single signal.
  4. Note 4: Where the request came from: the requesting workstation, not the domain controller that logged it.

Five fields, and once you know what each means for this event type, the whole event reads in seconds.

A Sysmon process event

Sysmon event 1, process creation, is the one you will read more than any other:

event.code:
"1"
process.name:
"powershell.exe" (note 1)
process.command_line:
"powershell.exe -enc <base64>" (note 2)
process.parent.name:
"winword.exe" (note 3)
process.parent.command_line:
"\"WINWORD.EXE\" /n quarterly_review.docm"
user.name:
"a.rivera"
  1. Note 1: PowerShell on its own tells you almost nothing: it runs constantly for normal reasons.
  2. Note 2: An encoded (-enc) command hides what the script does behind a base64 string.
  3. Note 3: The signal is the pairing: a word processor has no normal reason to launch PowerShell.

Read process events as a chain: what ran, what launched it, and what that launcher was doing at the time.

A Linux audit event

auditd records process execution through the kernel's audit framework, the closest Linux equivalent to the Sysmon event above:

event.module:
"auditd"
event.action:
"executed"
process.executable:
"/usr/bin/whoami" (note 1)
process.args:
["whoami"]
user.name:
"a.rivera"
auditd.data.auid:
"1003" (note 2)
  1. Note 1: What actually ran, the role process.name and the command line play on Windows.
  2. Note 2: The audit user ID: the original login user, kept even if the process later changes privilege. More reliable than user.name for finding who started a chain.

A bare execution event carries no parent-process link, so tracing lineage on Linux means correlating it with the events just before it.

A Zeek DNS record

Zeek's DNS log for a single query:

query:
"k7q2x9vz4m1t8b.cdn-sync.example" (note 1)
qtype_name:
"TXT" (note 2)
id.orig_h:
"192.0.2.57" (note 3)
proto:
"udp"
  1. Note 1: The shape matters as much as the content: a long, random-looking subdomain is not what normal lookups look like.
  2. Note 2: TXT records carry more data than an ordinary address record, which is why they are abused for tunneling.
  3. Note 3: The internal host that asked: your starting point.

Network records reward patterns over single lines: one query like this means little, a hundred from the same host in a short window means a lot.

A Suricata alert

Where Zeek gives you metadata to search, Suricata gives you a signature match:

event_type:
"alert"
alert.signature:
"Unusually long random subdomain in a name lookup" (note 1)
alert.severity:
1 (note 2)
src_ip:
"192.0.2.57"
dest_ip:
"203.0.113.44"
dest_port:
53
  1. Note 1: Start here: the signature is the reason this event exists, and its name usually says what the rule looks for.
  2. Note 2: On a 1 to 3 scale, lower is more severe: your first triage signal.

The rule already did the pattern matching. Your job shifts from finding the needle to confirming it and deciding what to do.

How to investigate

These queries are previews. Searching with KQL, the next unit, teaches the syntax.

  1. 1.

    Name the event type first.

    Filter to one event type before reading fields, so every field means one thing.

    event.code: "4769"
  2. 2.

    Find the actor.

    Identify the user, process or host that caused the event, and read it together with its partner field.

    process.parent.name: "winword.exe" and process.name: "powershell.exe"
  3. 3.

    Follow the relationship backward.

    Parent process on Windows; the preceding events for the same audit user ID on Linux; the earlier queries from the same host on the network.

  4. 4.

    Compare with normal.

    Ask whether that user or machine normally behaves this way. A single event is a data point; how often it happens compared with every other host is the finding.

    winlog.event_data.TicketEncryptionType: "0x17"
  5. 5.

    Widen the time range before you doubt the query.

    A correct query over the wrong window returns nothing. Widen it, confirm you can see data at all, then shorten it again.

Common mistakes

  • Mistake: Reading one field in isolation.

    InsteadRead pairs: a process with its parent, an account with the host it came from.

  • Mistake: Assuming a field means the same thing everywhere.

    InsteadCheck the event type first; the same field name can mean different things in different events.

  • Mistake: Searching a field in the wrong family.

    Insteadevent.code lives in Windows event logs. Network records do not have it, so a query there quietly returns nothing.

  • Mistake: Trusting user.name after a privilege change on Linux.

    InsteadUse the audit user ID to find who started the chain.

  • Mistake: Letting one alert stand for the whole story.

    InsteadA signature says traffic matched a rule. Confirm it with the traffic and the host before you conclude anything.

Field references

FieldWhat it tells youSeen in
event.codeWhich event this is: a Windows or Sysmon event ID.Windows Security, Sysmon
winlog.event_data.TicketEncryptionTypeEncryption type of a Kerberos ticket; 0x17 is RC4.Windows Security (4769)
process.name, process.parent.nameThe process that ran and the process that started it.Sysmon
process.command_lineThe full command, where intent often shows directly.Sysmon
user.nameThe account the activity ran as.Sysmon, auditd
auditd.data.auidThe original login user, kept across privilege changes.auditd
query, qtype_nameThe name looked up and the record type asked for.Zeek DNS
id.orig_hThe host that started the connection or query.Zeek
alert.signature, alert.severityThe rule that matched and how severe it is (1 is most severe).Suricata

Check yourself

  1. 1.
    A process-creation event shows a program with an ordinary-sounding name. Which fields tell you most about whether it belongs?

  2. 2.
    On a Linux audit record, someone logged in as a regular user and then switched to root. Which field still identifies the person who logged in?

  3. 3.
    You search one log source for a host and find nothing. What can you conclude?

  4. 4.
    A network intrusion-detection alert fires on a connection. What does the alert prove by itself?

Apply it in a Case

Pick a case with telemetry you have not read yet. Before you search for anything, read three of its events field by field and answer the four questions for each.

Browse every case on the Range →

References

Related in Learn

Which events to collect

The Telemetry reference lists, for each log source in this unit, the events worth collecting and why: the techniques each one helps detect, the rules that depend on it, and the standards that name it.