Threat hunting with Cortex Query Language works best when the analyst starts with a hypothesis, not a giant query. XQL can search endpoint, network, identity, cloud, and imported datasets, but the language is only useful when the hunt has a clear question: Which hosts contacted this destination? Where did this process tree appear? Which users authenticated from an unusual pattern? Which assets show the same behavior as the current incident?<\/p>\n
The current XSIAM Analyst<\/a> certification explicitly includes threat hunting, while the XSIAM Engineer<\/a> role covers deeper platform and data engineering. Analysts should therefore be comfortable turning investigative questions into efficient XQL stages and interpreting the results in context.<\/p>\n A hunt should state the suspicious behavior, relevant entities, likely timeframe, and evidence that would support or reject the hypothesis. \u201cFind malware\u201d is too broad. \u201cFind endpoints where a script interpreter launched from an Office process and then connected to a rare external destination during the last 24 hours\u201d is specific enough to guide fields and filters.<\/p>\n Write the hypothesis in plain language first. This helps avoid adding query stages simply because they are available. It also makes the hunt repeatable: another analyst can run the same logic later or convert it into a scheduled query or detection if the behavior proves important.<\/p>\n XQL queries require data to search. In many environments, Dataset choice affects both field names and query coverage. A hunt that assumes endpoint fields will not work against an unmapped identity dataset. Before troubleshooting syntax, confirm that the expected source is ingested, retained for the required period, and visible to the analyst\u2019s role. Missing data is a collection problem, not an XQL problem.<\/p>\n XQL uses stages separated by pipes. A practical query often starts with the dataset or data model, filters to the behavior of interest, selects or transforms fields, aggregates if necessary, and sorts or limits the results. Keep stages readable enough that another analyst can understand why each one exists.<\/p>\n Prefer early filters that reduce the result set. Narrow by time in the interface, then use selective conditions on process names, destinations, users, or event types. Return only the fields needed for the question. This improves query performance and makes the result table easier to interpret.<\/p>\n Some hunts need context from more than one dataset. A suspicious cloud permission event may become more meaningful when joined with asset inventory. A network connection may need endpoint process context. A user event may need identity or risk attributes from another source. XQL joins can connect those views when keys and data quality support the relationship.<\/p>\n Do not join datasets reflexively. Joins can increase query cost and create misleading duplicates if the key is not unique. Validate the relationship with a small sample first, and understand whether the join is one-to-one, one-to-many, or many-to-many.<\/p>\n Usernames, hostnames, IP addresses, and process paths often appear in different formats across sources. XSIAM provides normalized fields through its data model and in some raw datasets. Use normalized identity fields where appropriate so Define the hypothesis before opening Query Builder<\/h2>\n
Choose the right dataset or data model<\/h2>\n
xdr_data<\/code> is the default dataset and contains raw telemetry from Cortex agents and Palo Alto Networks sources. XSIAM can also query third-party datasets and the normalized Cortex Data Model when those sources are mapped appropriately.<\/p>\nBuild queries as readable stages<\/h2>\n
Use joins when the question crosses data sources<\/h2>\n
Normalize entities before comparing them<\/h2>\n
DOMAIN\\user<\/code>, an email address, and a local username do not become three apparently unrelated entities.<\/p>\n