EDR ✓ fields verified against sample logs

CrowdStrike Falcon Event Log Fields: Reference With Examples

Published

One JSON record per event a Falcon sensor reported — a process launch, network connection, DNS lookup, logon, or a detection raised by the Falcon cloud — identified by event_simpleName and tied to one sensor by aid.

Sample record

{"timestamp":"1705312920000","event_simpleName":"UserLogon","cid":"abc123def456","aid":"sensor001","ComputerName":"DESKTOP-ALICE","UserName":"CORP\\alice","LogonType":"2","RemoteAddressIP4":"10.0.0.10"}
{"timestamp":"1705313100000","event_simpleName":"DnsRequest","cid":"abc123def456","aid":"sensor001","ComputerName":"DESKTOP-ALICE","DomainName":"www.google.com","aip":"10.0.0.10"}

From the LogTriage parser test corpus — synthetic data, no real hosts or users.

Field reference

Field Type Meaning Why it matters for security
timestampe.g. 1705312920000 epoch milliseconds (string in these samples) When the sensor recorded the event. Divide by 1000 before joining with logs that use epoch seconds; order events per aid to rebuild an attack sequence.
event_simpleNamee.g. ProcessRollup2 string The event type, which determines which other fields are present. The first thing every parser and query must branch on — ProcessRollup2 for process execution, NetworkConnectIP4 for outbound connections, DnsRequest for name resolution, UserLogon for logons, DetectionSummaryEvent for detections.
aide.g. sensor001 string Agent ID — identifies the Falcon sensor installation the event came from. The stable join key across all events from one endpoint; more reliable than ComputerName, which users and admins can change.
cide.g. abc123def456 string Customer ID — the Falcon tenant the sensor belongs to. Separates environments in MSSP or multi-tenant data feeds so one customer's events are not counted against another's.
ComputerNamee.g. DESKTOP-VICTIM string Host name reported by the endpoint. The human-readable pivot for analysts and for correlating with Windows event logs and EDR tickets.
UserNamee.g. Administrator string The account associated with the event, as DOMAIN\user or a bare account name depending on the event. Not present on every event type; absent on some detection and DNS records, so do not filter on it when hunting broadly.
ImageFileNamee.g. C:\\Windows\\System32\\cmd.exe string Full path of the executable involved in the event, written with JSON-escaped backslashes. Execution from user-writable directories such as C:\Temp, or tooling named after known credential-theft utilities, is worth immediate review.
CommandLinee.g. cmd.exe /c powershell -enc JABjAGwAaQBlAG4AdA string Command line of the process in process events. Encoded PowerShell, download cradles and living-off-the-land flags are visible here; decode base64 arguments before judging.
SHA256HashDatae.g. e3b0c44298fc1c149afb4c8996fb92427ae41e4649b934ca495991b7852b855 string SHA-256 of the file involved in the event, where the sensor computed one. The value to send to threat intel and to search for the same binary on other hosts; verify the hash is full length before matching.
aipe.g. 10.0.0.10 IPv4 The IP address recorded for the sensor itself on this event. Useful for grouping events by network segment or egress point; in these samples it matches the host's internal address.
RemoteAddressIP4e.g. 10.0.0.10 IPv4 The far-end IPv4 address — the destination on network connections, the source on logon events. Its meaning depends on event_simpleName, so read it together with the event type before calling an address "external".
RemotePorte.g. 4444 integer Destination port on network connection events. Repeated connections to unusual high ports from one process are the classic shape of beaconing.
LogonTypee.g. 2 string (Windows logon type) Windows logon type on logon events — 2 is an interactive console logon. Network (3) and RemoteInteractive (10) logons from internal hosts are the ones to review for lateral movement.
DetectNamee.g. Cobalt Strike Beacon string Name of the detection raised on a DetectionSummaryEvent. The Falcon verdict; pivot from it to the raw ProcessRollup2 and NetworkConnectIP4 events on the same aid and timeframe.
Severitye.g. Critical string Severity assigned to the detection. Drives triage order, but a low-severity detection on a server or domain controller can still be the start of an intrusion.
Tactice.g. Command and Control string MITRE ATT&CK tactic attributed to the detection, alongside Technique. Lets you group detections by attack stage — credential access and command and control on the same host within minutes is an escalation.

What it records

Each line is one JSON object describing a single event observed by a CrowdStrike Falcon sensor, or a detection raised about those events. The event_simpleName field names the event type and decides which other fields exist: ProcessRollup2 for a process that ran, with ImageFileName, CommandLine and hash fields; NetworkConnectIP4 for an outbound connection, with local and remote addresses and ports; DnsRequest with DomainName; UserLogon and UserLogonFailed2 for authentication; DetectionSummaryEvent for a detection with DetectName, Severity, Tactic and Technique.

Every record carries the identity of its source — cid for the tenant, aid for the sensor installation — plus a millisecond timestamp and usually ComputerName. The samples on this page are abridged; real sensor records carry many more fields per event type.

Where to get it

  • Falcon console: detections and event search in the UI, for triage and for pulling the surrounding timeline of a single host.
  • Falcon Data Replicator, where it is provisioned for your tenant, delivers raw sensor telemetry to an S3 bucket, typically as gzip-compressed newline-delimited JSON — the form the samples here imitate.
  • Streaming/Event Streams API, which pushes detection and audit events to a SIEM connector as they are raised.

Which event types you receive, and which fields each one contains, depends on sensor version and platform; CrowdStrike documents the per-event schema in the Falcon console rather than in a single public field list, so confirm against your own data before building parsers.

Parsing pitfalls

  • No fixed column set. There is no common schema across event types. A flattening parser that assumes the fields from one event_simpleName will drop data from the others.
  • Mixed JSON types. In these samples LogonType is the string "2" and RemotePort is the number 4444. Normalise types on ingest instead of comparing strings to integers.
  • Milliseconds, not seconds. timestamp is epoch milliseconds, and it appears quoted as a string.
  • Escaped backslashes. Windows paths and DOMAIN\user values are JSON-escaped (CORP\\alice, C:\\Windows\\System32\\cmd.exe). Decode once; double-unescaping corrupts the path.
  • The meaning of address fields shifts. RemoteAddressIP4 is the destination on a network connection and the source on a logon event. aip describes the sensor’s own address, not the peer.
  • Fields are missing, not null. UserName is absent from the DNS record in the benign sample and from the detection record in the malicious one. Queries that require it silently lose events.
  • Hashes may be absent or malformed. Only some events carry MD5HashData or SHA256HashData; check length before matching against intel feeds.

Detection ideas

  • Encoded PowerShell launched from cmd.exe: ProcessRollup2 where CommandLine contains powershell -enc, then decode the base64 argument.
  • Beaconing: repeated NetworkConnectIP4 events from one aid to the same RemoteAddressIP4 and RemotePort at regular intervals, especially non-standard ports such as 4444.
  • Credential theft tooling: ImageFileName under user-writable paths like C:\Temp with names associated with dumping utilities — the endpoint analogue of the Sysmon LSASS dumping rule.
  • Anonymous logon failures against a domain controller: bursts of UserLogonFailed2 on a DC with SubjectUserName of ANONYMOUS LOGON, which pairs with Windows 4625 spray detection on the same host.
  • Detection-first triage: start at DetectionSummaryEvent records with high Severity, then pull every event sharing the same aid in the surrounding minutes to see what ran before and after.

The free browser analyzer parses JSON exports like these locally without uploading them.

Detections and guides for CrowdStrike Falcon

Frequently Asked Questions

What is the difference between aid, cid and ComputerName?
The aid identifies one Falcon sensor installation, the cid identifies the Falcon tenant the sensor is enrolled in, and ComputerName is whatever host name the endpoint reports. Use aid as the join key in queries, because host names are renamed and reused while an aid stays with the sensor installation.
Why do different records have completely different fields?
The schema is per event type. A ProcessRollup2 record carries process fields such as ImageFileName and CommandLine, a NetworkConnectIP4 record carries address and port fields, and a DetectionSummaryEvent carries DetectName, Severity, Tactic and Technique. Parse on event_simpleName first and treat every other field as optional.
How do I convert the timestamp field?
It is epoch time in milliseconds, written as a string in these samples. Divide by 1000 before comparing with Unix-second sources such as VPC flow logs, or parse it directly as milliseconds. Treating it as seconds puts the event tens of thousands of years into the future.
Do these records tell me whether Falcon blocked the activity?
Not on their own. The raw telemetry events record what the sensor observed; the detection and its verdict appear as a separate DetectionSummaryEvent. Prevention outcome depends on the policy applied to that host, which you confirm in the Falcon console rather than from these fields.

Analyze CrowdStrike Falcon logs

LogTriage auto-detects this format, enriches every IP, user agent and hash with threat intelligence, and writes an incident report mapped to MITRE ATT&CK.

Try Live Demo → Analyze Your Own Logs