What is the difference between LEEF and CEF?

Both are single-line, pipe-delimited header formats carrying key=value attributes, but they are different specifications from different vendors. LEEF is IBM's format for QRadar and separates its attributes with a delimiter (tab in these samples); CEF puts its extension as space-separated key=value pairs. The header components and the predefined key names differ, so a CEF parser will not read LEEF correctly.

Why does my parser return one giant field instead of src, dst and sev?

Almost always a delimiter problem. The attributes in these samples are tab-separated, and a parser splitting on spaces sees "cat=Firewall Allow" and "msg=HTTPS connection allowed" as broken pairs. Split on the actual delimiter — for LEEF 2.0 the header's sixth component names it, written here as x09 for tab.

Is sev always a number from 1 to 10?

Do not assume it. One line in the attack sample carries sev=critical from a PAN-OS threat event, so a parser that casts sev to an integer will drop or mangle the highest-severity record. Store it as a string, map per product, and alert on the device's own category as well as on severity.

Which timestamp should I trust, the syslog one or devTime?

Use devTime for ordering events from the same device, because it is the time the device assigned to the event, while the leading syslog timestamp is when the relay saw the line. Neither carries a timezone or year in these samples, so record the sender's configured timezone before you build a timeline across sources.

SIEM ✓ fields verified against sample logs

LEEF Log Format (IBM QRadar): Field Reference With Examples

Published October 29, 2026

One line per event in IBM's Log Event Extended Format: a pipe-delimited header naming the LEEF version, vendor, product and event type, followed by delimiter-separated key=value attributes describing what happened.

Sample record

Jan 15 09:00:01 siem-server LEEF:1.0|IBM|QRadar|7.3|FirewallAllow|src=203.0.113.10	dst=10.0.0.50	srcPort=52100	dstPort=443	proto=TCP	action=accept	sev=3	cat=Firewall Allow	usrName=deploy	devTime=Jan 15 2024 09:00:01	msg=HTTPS connection allowed
Jan 15 09:05:00 siem-server LEEF:1.0|IBM|QRadar|7.3|AuthSuccess|src=203.0.113.10	dst=10.0.0.50	srcPort=52200	dstPort=22	proto=TCP	action=allow	sev=2	cat=Authentication Success	usrName=deploy	devTime=Jan 15 2024 09:05:00	msg=SSH public key authentication successful
Jan 15 09:10:00 siem-server LEEF:2.0|Microsoft|Azure AD|1.0|SignInSuccess|x09|src=203.0.113.50	dst=login.microsoft.com	proto=HTTPS	action=allow	sev=1	cat=Authentication	[email protected]	devTime=Jan 15 2024 09:10:00	msg=MFA verified sign-in
Jan 15 10:00:00 siem-server LEEF:1.0|Palo Alto Networks|PAN-OS|10.1|traffic|src=203.0.113.10	dst=10.0.0.100	srcPort=60000	dstPort=80	proto=TCP	action=allow	sev=1	cat=web-browsing	request=http://internal.corp.com/dashboard	devTime=Jan 15 2024 10:00:00

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

Explain this record field by field →

Field reference

Field	Type	Meaning	Why it matters for security
srce.g. 203.0.113.10	IPv4/IPv6 or hostname	Source address of the activity as the sending device saw it.	The main pivot — group failures, blocks and scans by src to see one actor across devices.
dste.g. 10.0.0.50	IPv4/IPv6 or hostname	Destination address or host the activity was aimed at.	Shows which internal asset was touched; one src against many dst values is sweeping.
srcPorte.g. 52100	integer	Source port of the connection.	Usually ephemeral and uninteresting on its own, but useful to tie a block back to a specific flow.
dstPorte.g. 443	integer	Destination port of the connection.	Many distinct dstPort values from one src is a port scan; 22 and 3389 from outside deserve attention.
protoe.g. TCP	string	Transport or application protocol recorded by the device.	Devices write it inconsistently (TCP, HTTPS in the samples), so normalize before comparing across vendors.
actione.g. accept	string	What the device did with the event.	Vendor-specific wording — the samples use accept, allow, block, deny and blocked — so map values per product before writing a rule that keys on "blocked".
seve.g. 3	string or integer	Severity assigned by the sending device.	Not guaranteed numeric — one sample line carries sev=critical — and the scale means different things per product, so do not compare raw values across vendors.
cate.g. Firewall Allow	string	Device-side category or event class.	The quickest filter for a hunt (Authentication Failure, sql-injection, Intrusion Detection in these samples), but the vocabulary is per product.
usrNamee.g. deploy	string	Account associated with the event.	Counting distinct usrName values per src separates one user with a bad password from credential guessing.
devTimee.g. Jan 15 2024 09:00:01	string	Time of the event according to the sending device.	Prefer it over the syslog timestamp for sequencing, but confirm the device's timezone — these lines carry no offset and no devTimeFormat attribute.
msge.g. HTTPS connection allowed	string	Free-text description from the device.	Often the only place the real reason appears; keep it in the alert so the analyst does not have to re-open the raw log.
requeste.g. http://internal.corp.com/dashboard	string	URL or request string for web and threat events.	Where injection and traversal payloads show up; values contain spaces, so never split a LEEF line on whitespace.

Have one of your own records? Paste it into the log line explainer and each field is explained from this table, with times, codes and addresses decoded — in your browser.

What it records

LEEF — Log Event Extended Format — is IBM’s single-line event format, designed for sending events to QRadar. Each line is one event and has two parts.

The second part is a list of key=value attributes separated by that delimiter. LEEF defines a set of predefined keys that receivers map to normalized fields — src, dst, srcPort, dstPort, proto, sev, usrName, cat — and devices are free to add their own keys, such as the request attribute on the PAN-OS lines here.

What LEEF does not do is normalize meaning. The samples carry firewall allows and denies from QRadar, Entra ID sign-ins, PAN-OS traffic and threat events, and a Symantec intrusion record. All four use the same syntax and completely different vocabularies for cat, action and sev. LEEF is a transport wrapper: it makes the line parseable, not comparable.

Where to get it

LEEF is normally emitted over syslog by a device or by an integration configured to “send events to QRadar”, so the faithful copy is the file your syslog receiver writes before anything parses it — /var/log/ on an rsyslog or syslog-ng relay, as in these samples, where each LEEF line sits behind a standard syslog header (Jan 15 09:00:01 siem-server). If the events already reached QRadar, the raw payload stored with the event is the same line you see here.

When you pull a sample for analysis, take whole lines including the syslog prefix. The prefix tells you which relay received it and when, which matters when a device’s clock is wrong.

Parsing pitfalls

Strip the syslog header first. The LEEF record begins at LEEF:. Everything before it belongs to the transport.
Split on the declared delimiter, not on whitespace. Values legitimately contain spaces (cat=Firewall Allow, msg=Port scan detected from external IP, and a request value containing ?id=1 UNION SELECT). Whitespace splitting silently corrupts exactly the events you care about.
Header component count varies. LEEF 1.0 lines have five components before the attributes; LEEF 2.0 lines may have six, the extra one being the delimiter. Count fields rather than assuming a position.
The fifth header component is vendor-specific. FirewallDeny, AuthFailure, traffic, threat and Intrusion all appear here; correlate it with vendor and product, never on its own.
sev is not reliably numeric and its scale is per product.
devTime has no format attribute in these samples. There is no devTimeFormat and no timezone, so a parser has to be told how to read Jan 15 2024 14:30:01.
Attributes are optional. The PAN-OS traffic line has no msg; the Symantec line has no ports. Treat missing keys as normal, not as parse errors.

Detection ideas

Brute force and credential guessing: repeated events with cat=Authentication Failure (or the equivalent EventID, here AuthFailure) from one src, especially against dstPort=22. Count distinct usrName values per src to separate one locked-out user from spraying.
Blocked exploit attempts: a high sev together with a blocking action and a category such as sql-injection or Intrusion Detection — the device already stopped it, so the question is what else that src touched.
Injection payloads in request: SQL keywords, traversal sequences or encoded payloads in the URL attribute of web and threat events.
Scanning: one src producing deny or block events across many dstPort or dst values in a short window.
Authentication anomalies from identity sources: LEEF-wrapped Entra ID events carry the outcome in cat and msg; pair them with the AADSTS code reference when the original sign-in log is available, since LEEF usually drops the detail.

Because every vendor fills cat, action and sev differently, build detections per Vendor|Product pair first and normalize afterwards. For the sibling format with the same shape but different keys, see the CEF reference; to test parsing on a sample without uploading it, use the browser log analyzer.

Sending IBM LEEF to an LLM

One megabyte of this format is about 592,120 tokens on current Claude models and 404,503 on GPT models, measured with the models' own tokenizers — so a gigabyte sent raw to Claude Sonnet 5.5 costs about $1,184 in input tokens alone (prices of 2026-10-24). Estimate your own volume →

Frequently Asked Questions

What is the difference between LEEF and CEF?: Both are single-line, pipe-delimited header formats carrying key=value attributes, but they are different specifications from different vendors. LEEF is IBM's format for QRadar and separates its attributes with a delimiter (tab in these samples); CEF puts its extension as space-separated key=value pairs. The header components and the predefined key names differ, so a CEF parser will not read LEEF correctly.
Why does my parser return one giant field instead of src, dst and sev?: Almost always a delimiter problem. The attributes in these samples are tab-separated, and a parser splitting on spaces sees "cat=Firewall Allow" and "msg=HTTPS connection allowed" as broken pairs. Split on the actual delimiter — for LEEF 2.0 the header's sixth component names it, written here as x09 for tab.
Is sev always a number from 1 to 10?: Do not assume it. One line in the attack sample carries sev=critical from a PAN-OS threat event, so a parser that casts sev to an integer will drop or mangle the highest-severity record. Store it as a string, map per product, and alert on the device's own category as well as on severity.
Which timestamp should I trust, the syslog one or devTime?: Use devTime for ordering events from the same device, because it is the time the device assigned to the event, while the leading syslog timestamp is when the relay saw the line. Neither carries a timezone or year in these samples, so record the sender's configured timezone before you build a timeline across sources.

Analyze a IBM LEEF file in your browser

The free analyzer detects this format, parses every field above and flags attack patterns — the file never leaves your machine. For threat-intel enrichment and an AI-written incident report, run it through LogTriage.

Open the free analyzer → Analyze your own logs

Investigating something right now? LogTriage checks every address in the file against threat intelligence and writes the incident report: 10 analyses a month free. The incident pack adds the in-depth AI analysis and files up to 100 MB: 25 analyses for $19, one payment, no subscription. Pricing