CrowdStrike Certified Falcon Hunter (CCFH) Practice Tests

Explanation

Falcon Spotlight's ExPRT.AI (Expert Priority Rating) is an AI-driven vulnerability prioritization engine that combines three critical factors to produce actionable risk rankings: exploitability (whether the CVE has known exploit code active in the wild), asset criticality (the business importance of the affected system to the organization), and adversary activity (whether tracked threat actor groups are actively exploiting the vulnerability in real-world intrusions). This multi-factor approach directly solves the described problem — a high-CVSS theoretical vulnerability on a non-critical system with no exploit code receives lower priority than a medium-CVSS vulnerability being actively weaponized by ransomware groups against business-critical infrastructure. CVSS score alone is a suboptimal prioritization criterion because CVSS scores represent theoretical severity ratings that do not account for real-world exploitability in the current threat landscape, asset context, or active threat actor behavior. Sorting by disclosure date inverts rational priority logic — older vulnerabilities with mature exploit tooling embedded in adversary arsenals are often more immediately dangerous than newly disclosed theoretical flaws without public proof-of-concept code. Filtering only by system type and focusing exclusively on domain controllers ignores critical vulnerabilities on other high-value assets such as database servers, backup infrastructure, and administrative jump hosts.

Explanation

Hypothesis-driven hunting is defined by the hunter constructing an original investigative hypothesis about how malicious activity might manifest in the telemetry, then designing queries to test that hypothesis. In this scenario, the hunter applies the outlier analysis principle — the observation that adversary tools, being introduced into an environment for the first time, appear on very few hosts while widely-used legitimate software appears across many endpoints. This hypothesis is tested through CQL queries that measure process prevalence across the endpoint fleet using groupBy() and count(). The approach originates entirely from the hunter's own analytical reasoning without any external trigger. Intel-driven hunting is initiated by a specific external intelligence source documenting a named adversary's confirmed techniques with specific behavioral indicators to target. Situational awareness hunting is triggered by changes to the organizational environment itself, such as a cloud migration, new software rollout, or significant configuration change. Reactive hunting begins from an existing Falcon detection or alert and pivots into deeper investigation — in this scenario, no prior detection exists.

Explanation

The Process Timeline is specifically designed to visualize parent-child process relationships and reconstruct the execution chain of an attack in a graphical format. It allows analysts to trace the exact sequence — such as an email client opening a document, which spawns Word, which executes a PowerShell script, which then injects into a legitimate process like notepad.exe. This tool quickly surfaces the origin of the attack and every subsequent step in the process execution chain. The Host Timeline provides a useful chronological view of all endpoint events but does not specifically visualize the hierarchical process relationships needed to trace injection chains. Bulk Domain Search is valuable for lateral spread analysis but does not reconstruct a process execution flow. CQL Event Search in the Event Search module is powerful but requires more time and query expertise compared to the visual Process Timeline for this specific reconstruction task.

Explanation

Effective outlier hunting for rare processes requires two key CQL elements. First, the query must begin with the ProcessRollup2 tag filter using #event_simpleName=ProcessRollup2, which scopes the search to process creation events — the correct event type for analyzing process image file names. Tag filters must always appear first in a CQL query for performance, as they are pre-indexed at ingest and prevent costly full table scans. Second, the rare() function is specifically designed to surface the least frequently occurring values of a given field, making rare(ImageFileName) the correct analytical function for identifying process names that appear on the fewest hosts across the enterprise. Using NetworkConnect as the tag filter would scope the query to network connection events, which contain different fields and would miss process naming context. The groupby(ComputerName) function aggregates by host rather than by process name, inverting the intended analysis direction. The table() output function displays results without frequency-based ranking, requiring manual review to identify outliers rather than surfacing them automatically.

Explanation

Tag filters using the # prefix syntax — such as #event_simpleName=ProcessRollup2 or #type=falcon-raw-data — are pre-indexed fields in Falcon Next-Gen SIEM. Because they are indexed at data ingest time rather than at query execution time, tag filters allow the query engine to instantly narrow the search scope to only the relevant event category without scanning the full data store. Placing a tag filter first in every CQL query is a foundational performance best practice that becomes critical at enterprise data volumes. Queries without leading tag filters perform full table scans across all stored events, causing significant performance degradation. Tag fields carry an additional constraint that distinguishes them from regular fields: they support only exact match comparisons and cannot use regex patterns or wildcard characters. The groupBy() function performs aggregation and is useful for analytical queries, but it is not a required structural element — many valid CQL queries return raw individual event records without any aggregation. The table() output function simply defines which fields appear in query output and can be omitted without affecting query correctness or execution. While CQL does apply default result limits, a limit() clause is not a required structural element and its absence does not cause the performance issue described.