Free Practice Questions for CrowdStrike CCFH-202b Exam

In the discipline of Hunting Methodology , identifying "hidden in plain sight" directories is a primary objective for uncovering persistent threats. The Recycle Bin ($Recycle.Bin) is considered a highly suspicious directory for process execution because legitimate applications are almost never designed to run from this location. Adversaries frequently utilize this path to stage malicious binaries, as it is a directory that is often overlooked by manual administrative review and some legacy security tools (MITRE ATT & CK T1564.001 - Hidden Files and Directories).

The query in Option C correctly addresses the two specific requirements of the prompt. First, it uses the wildcard aid=* to ensure the hunt is performed across all hosts in the enterprise, providing a global view rather than focusing on a single machine (as seen in Option B). Second, it utilizes a regular expression /\$Recycle\.Bin/i to filter for any ProcessRollup2 events where the ImageFileName originates from the Recycle Bin. While directories like "Downloads" or "Desktop" can also be used for staging, they are significantly "noisier" in a production environment as legitimate users frequently run installers from those paths. By targeting the Recycle Bin and using the groupBy function to aggregate the SHA256HashData, a hunter can quickly identify unique, unauthorized binaries that have been moved to a hidden area to evade detection. This proactive approach allows the security team to identify the "Patient Zero" host and any subsequent lateral movement involving the same malicious hash.

In the context of Search and Investigation Tools , the BIOS Analysis dashboard is a specialized forensic resource that provides deep visibility into the firmware health of the managed fleet. While "BIOS Firmware Inventory" (Option D) provides a flat list of current versions across the organization, the BIOS Analysis dashboard is uniquely designed to correlate that inventory data with known vulnerabilities and historical change events.

For a hunter, this dashboard is essential for identifying systems at risk of hardware-level persistence or "Bootkit" attacks. It provides a detailed timeline of firmware updates and changes, allowing an investigator to see exactly when a BIOS version was modified—which is critical if an adversary has attempted to flash a malicious or vulnerable firmware image. Furthermore, the dashboard categorizes vulnerabilities by type and severity, mapping them to specific CVEs (Common Vulnerabilities and Exposures). This level of detail allows security teams to prioritize patching for the most critical assets first. By moving beyond simple inventory and into behavioral and vulnerability analysis of the BIOS, the Falcon platform enables hunters to address threats that exist below the operating system level, ensuring a comprehensive security posture that extends from the hardware to the cloud.

In the context of Hunting Methodology , reconnaissance (often categorized under the Discovery tactic in the MITRE ATT & CK framework) involves an adversary gathering information about the internal network, host configurations, and user privileges. The query in Option D is specifically designed to hunt for this behavior by monitoring the execution of "Living off the Land" (LotL) binaries.

These built-in Windows utilities, while legitimate for administrative use, are the primary tools used by attackers to "get the lay of the land." Commands like whoami are used for System Owner/User Discovery (T1033), ipconfig and netstat for System Network Configuration Discovery (T1016), and tasklist for Process Discovery (T1057). By filtering for these specific filenames—net, ipconfig, whoami, quser, ping, netstat, tasklist, hostname, and at—on a specific host (aid), a hunter can identify a burst of discovery activity. While individual executions might be common, a series of these commands run in rapid succession by a non-administrative user is a high-confidence indicator of a compromise. This proactive search allows analysts to catch an adversary in the early stages of an attack, before they have successfully identified their next target for lateral movement or privilege escalation.

In the CrowdStrike Falcon Console's Process Tree view, hovering over a specific process node activates a summary window that displays Process Actions . These actions are represented by specific icons and numerical values that quantify the telemetry recorded for that process instance. Understanding these icons is a fundamental skill for Search and Investigation Tools usage, as it allows for a rapid "at-a-glance" triage of a detection without immediately pivoting to raw events.

As shown in the exhibit, the icons from left to right generally correspond to:

Child Processes/Branching : Represented by the branching node icon (Value: 7 ).

Network Operations : Represented by the antenna/signal icon (Value: 8 ).

DNS Requests : Represented by the purple bullseye/target icon (Value: 61 ).

Disk Operations : Represented by the document/page icon (Value: 4 ).

Registry Modifications : Represented by the shield icon (Value: 0 ).

Other Process Operations : Represented by the document with an arrow icon (Value: 2 ).

While standard iconography associates the "8" with Network Operations, Option C is the recognized correct answer within Falcon Hunter training materials to describe this specific exhibit. It accurately identifies 4 Disk Operations (matching the blue page icon), 61 DNS Requests (matching the purple target icon), and 2 Process Operations (matching the cross-process activity icon). This summary allows a hunter to immediately see that this powershell.exe process has been highly active, performing numerous DNS lookups and spawning several child processes, which is characteristic of a script attempting to reach out to Command and Control (C2) infrastructure or download additional payloads.

In Falcon Event Search , understanding the distinction between standard events and "synthetic" events is vital for accurate timeline reconstruction. A SyntheticProcessRollup2 event is specifically generated by the Falcon sensor to account for processes that were already running at the time the sensor started (e.g., during a system boot before the sensor service initialized, or when the sensor was first installed on an already-running machine).

Standard ProcessRollup2 events capture the actual start time and full metadata of a process as it executes. However, because the sensor cannot retroactively capture the exact moment of execution for pre-existing processes, it creates a "Synthetic" record. This ensures that the analyst still has visibility into the process's existence, its TreeId, and its associated metadata, even if the initial "start" event was missed. For a hunter, seeing a SyntheticProcessRollup2 in a detection chain is a significant clue; it indicates that the suspicious process may have been established as a persistence mechanism that survives reboots or was present on the system before security coverage was active. This helps the investigator differentiate between a brand-new infection and a legacy compromise that is only now being identified by the sensor's behavioral logic.

==========

The Falcon platform provides a variety of visual Reports and References designed to help security teams identify geographic anomalies that may indicate unauthorized access or compromised credentials. The Global connection heat map is a specialized dashboard that aggregates network telemetry and visualizes it based on the geographic origin of the connections associated with Falcon-managed hosts.

This report is a vital component of a hunter's toolkit for "Geofencing" or identifying "Impossible Travel" scenarios. By providing a high-level visual representation of where in the world host connections are originating, it allows analysts to quickly spot outliers—such as a connection from a country where the organization has no employees, offices, or known business interests. While the "Geo location activity" (Option A) might sound similar, the "Global connection heat map" is the specific built-in name for the dashboard that provides the density-based visualization required to distinguish between a single anomalous connection and a widespread, automated attack originating from a specific region. Once an anomaly is identified on the heat map, a hunter can pivot directly into the associated events to see which aid (Agent ID) is involved and what specific processes or users are initiating those suspicious international connections.

Identifying "rare occurrences" is a core technique in Hunting Analytics known as Least Frequency Analysis (LFA) . In a typical enterprise, standard web browsers and legitimate system services will generate millions of events with common UserAgentStrings . Adversaries, however, often utilize custom tools, scripts (like Python or PowerShell), or specialized Command and Control (C2) agents that leave behind unique or highly infrequent user agent signatures.

The query in Option C is the correct CrowdStrike Query Language (CQL) syntax to surface these outliers. The groupBy(UserAgentString, ...) function aggregates all events by their unique user agent. By including count() within the function, the query engine calculates exactly how many times each string has appeared over the specified 30-day window. The collect() function is then used to retain the investigative context—such as the ComputerName and UserName—associated with those strings without splitting the count. Finally, the query pipes the results into sort(_count, order=asc, limit=10). This critical sorting step ensures that the strings with the lowest counts (the "rare" ones) are pushed to the top of the list. This methodology allows a hunter to quickly bypass the "noise" of legitimate traffic and focus on potentially unauthorized tools or non-standard browser versions that could indicate a beachhead or data exfiltration activity.

In the context of Hunting Analytics , outlier analysis—often referred to as Least Frequency Analysis (LFA) or "Long-Tail Analysis"—is a methodology used to identify anomalous behavior by isolating events that occur rarely within a large dataset. Attackers often use unique command-line arguments or rare scripts that stand out when compared to the repetitive, high-volume "noise" generated by standard administrative activities or automated system processes.

In the provided CrowdStrike Query Language (CQL) query, Line 6 (| test(executionCount < 10)) is the specific line used to perform this outlier analysis. While Line 5 performs the aggregation and counting of events across the environment, it is Line 6 that applies a logic threshold to filter out common events. By instructing the engine to only return results where the executionCount is less than 10, the hunter is intentionally discarding all "normal" high-frequency activity and focusing exclusively on rare executions. This is a critical step in a PowerShell hunt, as most legitimate enterprise scripts will run hundreds or thousands of times, whereas a malicious manual execution or a new, untested exploit script will typically have a very low execution count. Line 7 further assists by sorting these outliers in ascending order, but the actual analytical "test" that defines the outlier occurs in Line 6. Utilizing such thresholds allows hunters to efficiently sift through millions of events to find the "needles in the haystack" that represent potential security breaches.

Efficiency is a critical skill in Event Search , especially when dealing with the high-velocity telemetry generated by thousands of endpoints. When a query returns millions of events, it not only becomes difficult for a human to analyze but also consumes significant computational resources, leading to longer wait times. The most effective way to optimize performance and increase the signal-to-noise ratio is by Filtering the results to remove irrelevant events .

In the CrowdStrike Query Language (CQL) , filtering should be performed as early as possible in the query pipeline (the "left-most" part of the query). By using specific inclusion filters (e.g., FileName="cmd.exe") or exclusion filters (e.g., FilePath!=/\\Windows\\System32\\.*/i), the hunter instructs the engine to discard millions of non-matching records before they are even processed by more resource-intensive functions like groupBy() or join(). While aggregating data (Option A) can help summarize a large dataset, it does not necessarily decrease the initial "ingest" or "scan" time of the query if the engine still has to look at every record. Strategic filtering allows the hunter to focus exclusively on the "interesting" metadata, such as files running from temp directories or signed by unusual certificates, ensuring that the hunt remains fast, responsive, and relevant to the threat model.