Quick Navigation
CQL Pipe Syntax and Filtering (25%)CQL Aggregation Functions (25%)CrowdStrike Parsing Standard (CPS)Detection Types and Alert Metadata (25%)MITRE ATT&CK Framework (25%)Incident Investigation — Event Chain Construction (40%)Incident Investigation — Response and Containment (40%)Correlation Rules vs. CQL Search Queries (25%)Dashboards and Visualizations (25% + 10%)Case Management and Reporting (10%)Attack Pattern Recognition — Lateral Movement and PersistenceKey Exam Distinctions and Common Traps
CQL Pipe Syntax and Filtering (25%)
- Basic pipe syntax
- CQL chains operations with | — each stage transforms the result set: filter | aggregate | transform | display.
- event.action=failed_login | source.ip=*
- Filter on event type using CPS field, then further restrict to rows where source.ip has any value; implicit AND between pipe-chained filters.
- OR binds closer than AND
- 'A AND B OR C' evaluates as 'A AND (B OR C)' — use explicit parentheses to enforce intended logic whenever mixing AND and OR operators.
- Free-text search vs. field filter
- Unquoted terms match anywhere in the raw event line; field=value restricts to a specific field — use field filters for precision and performance.
- Wildcard matching: field=value*
- Trailing wildcard matches any string starting with 'value'; field=* matches any event that has that field populated.
- NOT operator: NOT field=value
- Negates a match; example: NOT source.ip=10.0.0.0/8 excludes all RFC-1918 source addresses from results.
- Time range scoping
- Always scope investigation queries with a time window to limit scan volume and improve performance; unconstrained queries scan all retained data.
- // Single-line and /* multi-line */ comments
- CQL supports both comment styles inside queries; use them to annotate complex hunting scripts before saving.
CQL Aggregation Functions (25%)
- | top(user.name, limit=10)
- Counts occurrences of each field value and returns the top N ranked by frequency; top() handles both grouping and ranking internally — do NOT prepend groupBy().
- | groupBy(source.ip)
- Groups events by a field value and counts per group; use when you need all groups without a top-N limit.
- | groupBy(user.name, function=stats(count()))
- Combines groupBy with statistical aggregation; stats() supports count(), sum(), avg(), min(), max().
- | eval(label := concat(source.ip, ":", destination.port))
- Creates a new field using an expression; := is always required for field assignment inside eval() — using = performs a filter comparison, not assignment.
- | rename(field=old_name, as=new_name)
- Renames an existing field without changing its value; useful when normalizing results for dashboard display.
- | sort(field=count, order=desc, limit=100)
- Sorts result rows by the specified field; combine with groupBy() results to produce ranked tables.
- | timeChart(span=1d, function=count())
- Produces a time-series aggregation binned into intervals (1m, 1h, 1d, etc.) — the correct function for trend visualizations over time.
CrowdStrike Parsing Standard (CPS)
- CPS normalized field: source.ip
- CPS (based on Elastic Common Schema) provides standardized field names that work across ALL data sources — use CPS fields for cross-source queries.
- Key CPS fields: source.ip, destination.ip, user.name, event.action, host.name, process.name
- Core ECS-based fields shared across endpoint, network, identity, and cloud log sources in Falcon Next-Gen SIEM.
- Vendor-specific fields: Vendor.fw_action
- Fields with no ECS equivalent are prefixed with 'Vendor.' — they are preserved, never dropped, and queryable with the Vendor. prefix.
- CPS vs. raw vendor fields
- source.ip works across firewall AND identity logs; raw vendor field 'src_ip' may only exist in one source — always prefer CPS fields for cross-source queries.
- ioc:lookup() function
- | ioc:lookup(field=source.ip, type="ip_address") — queries CrowdStrike IOC intelligence inline within a CQL query for enrichment.
Detection Types and Alert Metadata (25%)
- First-party detections
- Generated natively by Falcon EDR, Identity Protection, and Cloud Security; include full process trees, user context, and ATT&CK mapping — richest investigation context.
- Third-party passthrough detections
- Alerts forwarded from external tools (firewalls, other EDRs, email gateways) via data connectors; may lack Falcon context and require correlation with additional sources.
- Correlation rule detections
- Generated when a persistent CQL-based rule matches conditions across incoming data; logic is analyst-configurable unlike native Falcon IOA detections.
- Alert Severity
- Indicates the potential impact if a detection is confirmed malicious — High severity = significant potential damage; does NOT indicate likelihood of being a true positive.
- Alert Confidence
- Indicates how likely the detection is a true positive based on detection logic quality — High confidence = closely matches known malicious patterns.
- Triage priority formula: Severity + Confidence
- High severity AND high confidence = investigate first; high severity + low confidence = investigate to validate; never auto-dismiss based on either dimension alone.
- IOCs (Indicators of Compromise)
- Static artifacts — IP addresses, file hashes, domain names, URLs — that are known malicious; reactive, used for correlation and enrichment.
- IOAs (Indicators of Attack)
- Behavioral patterns indicating an attack in progress regardless of specific tools used; Falcon's first-party detections are IOA-based, not signature-based.
MITRE ATT&CK Framework (25%)
- ATT&CK Tactics (adversary goals)
- Initial Access, Execution, Persistence, Privilege Escalation, Defense Evasion, Credential Access, Discovery, Lateral Movement, Collection, Exfiltration, Command and Control.
- Tactic vs. Technique distinction
- Tactics are adversary GOALS (what they want to achieve); techniques are specific METHODS to reach that goal — the same tactic can be achieved with many techniques.
- T1053.005 — Scheduled Task/Job: Scheduled Task
- Windows scheduled task creation for persistence; indicators include schtasks.exe execution, Task Scheduler event logs, and tasks running from temp directories.
- T1543.003 — Create or Modify System Process: Windows Service
- New service creation for persistence; indicators include sc.exe commands, registry modifications under HKLM\SYSTEM\CurrentControlSet\Services, and service binaries in temp paths.
- T1110 — Brute Force
- Multiple failed logins from same source IP followed by a success — the exam pattern for T1110; look for high volume authentication failures to the same account.
- T1021 — Remote Services (Lateral Movement)
- Using RDP, SSH, WMI, or SMB/admin shares to access other systems; evidence requires BOTH network connection logs AND authentication logs on target host.
- T1078 — Valid Accounts
- Attacker uses legitimate credentials (stolen, purchased, or dumped) to authenticate; detected via behavioral anomalies like impossible travel or off-hours logins.
Incident Investigation — Event Chain Construction (40%)
- Multi-source correlation requirement
- An investigation using only one data source is incomplete; always correlate network, endpoint, identity, email, and cloud logs to build the full event chain.
- Confirming lateral movement
- Requires BOTH: network logs showing connection from Source-A to Target-B AND authentication logs on Target-B showing successful login from Source-A credentials.
- Impossible travel detection
- Login from New York at 09:00 UTC followed by Tokyo login at 09:25 UTC = credential compromise — physical travel time (14h+) makes simultaneous access impossible.
- Impossible travel: geolocation + timestamp
- Always analyze BOTH geolocation AND the time gap together; a 24-hour gap between geographically distant logins may be legitimate travel rather than compromise.
- Observable pivoting sequence
- IP address → user account → hostname → process → file hash → threat intelligence; follow each connection to expand investigation scope.
- Persistence indicator — new service in temp directory
- Service binary running from %TEMP% or %APPDATA% rather than system directories is a strong persistence indicator; map to T1543.003.
- Privilege escalation indicator — LSASS access
- Process accessing lsass.exe memory (credential dumping) combined with new admin account creation indicates privilege escalation; map to T1003.001.
- Data retention awareness
- If logs are retained for 30 days but the incident started 45 days ago, the earliest portion of the timeline cannot be reconstructed — factor retention limits into scope assessments.
Incident Investigation — Response and Containment (40%)
- Falcon Fusion SOAR — host containment
- Use an existing SOAR workflow to contain a host with active C2 communication; stops the connection immediately while preserving forensic evidence.
- Active C2 communication — immediate response
- Confirmed active C2 = use SOAR containment workflow; do NOT just document and monitor — the attacker has an active channel and will take further action.
- SOAR workflows are EXISTING automation
- Analysts UTILIZE predefined SOAR workflows; building new workflows from scratch is a CCSE (engineer) responsibility — the CCSA exam tests workflow utilization, not creation.
- Response proportionality rule
- Match response severity to confirmed evidence; do not escalate to full host containment based on an unvalidated low-confidence detection — validate first, then respond.
- Contextual enrichment — geolocation
- Use geolocation to identify anomalous login origins; combine with IP reputation feeds to assess whether source infrastructure is known-bad or commercial VPN.
- Contextual enrichment — IP reputation
- Cross-reference source IPs against threat intelligence to determine if they belong to known threat actor infrastructure, TOR exit nodes, or commercial hosting.
- Scope assessment factors
- Number of affected hosts, sensitivity of compromised accounts/data, attacker capabilities demonstrated (lateral movement, privilege escalation), and dwell time all determine incident severity.
Correlation Rules vs. CQL Search Queries (25%)
- Correlation rule — purpose
- Persistent, always-on detection written in CQL that fires automatically when conditions are met against incoming data; generates alerts in the detection queue.
- CQL search query — purpose
- Ad-hoc or saved query run on-demand by analysts to investigate specific questions, hunt for threats, or explore data; does NOT generate automatic alerts.
- Same syntax, different execution
- Both correlation rules and search queries use CQL syntax — the distinction is execution model: rules are persistent and automated; queries are on-demand and manual.
- Prebuilt scripts
- Ready-made CQL hunting scripts provided by CrowdStrike for common threat scenarios; analyst-driven (on-demand) tools, NOT the same as correlation rules (automated).
- Correlation rule for brute force detection
- A rule firing on 10+ failed logins within 5 minutes from the same IP auto-generates an alert; an analyst running the same query manually produces results, not an alert.
- False positive differentiation requires context
- The same activity (PowerShell encoded commands) is malicious from an unknown user and potentially legitimate from a known admin — context, not just alert content, determines verdict.
Dashboards and Visualizations (25% + 10%)
- timeChart — trend over time
- Use timeChart(span=1d, function=count()) to show how detection volume changes over time — the correct visualization when asked 'how has X changed over 90 days'.
- groupBy — categorical comparison
- Use groupBy(source.ip) with a count to compare attack volumes across different source IPs — produces a ranked table, not a time series.
- top() — ranked frequency summary
- Use top(user.name, limit=10) to find the most targeted accounts; top() is more efficient than groupBy + sort + limit when ranking by frequency.
- Visualization type selection
- Bar chart = categorical comparison; time series = trends over time; table = detailed data with multiple fields; geographic map = login origin distribution.
- Dashboard for trend vs. real-time monitoring
- Reporting dashboards reveal trends and anomalies for communication; real-time monitoring dashboards feed the SOC — the CCSA exam tests the reporting/communication use case.
- Sankey diagram
- A specific dashboard visualization showing flow and relationships between categories; useful for visualizing attack progression or network traffic paths.
Case Management and Reporting (10%)
- Case Management purpose
- Documents investigations by aggregating related detections, analyst notes, evidence, and findings into a traceable case record — NOT for creating detections or configuring alerts.
- Case Management workflow
- Attach relevant detections to the case, add analyst notes at each investigation step, record final verdict and scope, and summarize findings for stakeholder communication.
- Leadership reporting format
- Executive audience: incident timeline, business impact, actions taken, recommended next steps in plain language — NOT raw CQL results, ATT&CK breakdowns, or full case logs.
- Case Management vs. dashboards
- Case Management captures the narrative of a specific investigation; dashboards visualize aggregate trends across many events — they serve different purposes and audiences.
- Reporting: technical vs. executive audience
- Security team reporting includes ATT&CK technique details and IOC lists; executive reporting summarizes business impact and recommended actions — calibrate to audience.
- Charlotte AI — AI-assisted investigation
- CrowdStrike's AI assistant integrated into Falcon; supports natural language querying, threat analysis acceleration, and triage suggestions — supplements analyst judgment, does not replace it.
Attack Pattern Recognition — Lateral Movement and Persistence
- Lateral movement indicators
- Remote logins to previously uncontacted hosts, RDP/SSH sessions from unexpected sources, WMI or PSExec execution, net use commands accessing admin shares, pass-the-hash/ticket patterns.
- Pass-the-Hash (PtH) indicator
- Successful NTLM authentication with no prior interactive logon on the source machine — indicates a stolen hash being replayed rather than a plaintext credential.
- Persistence: scheduled task creation
- schtasks.exe /create or Task Scheduler event 4698 (task created); malicious tasks often run from temp directories or use encoded PowerShell commands.
- Persistence: registry run key
- Modifications to HKCU\Software\Microsoft\Windows\CurrentVersion\Run or HKLM equivalent; process launching from these keys at user logon.
- Defense evasion: encoded PowerShell
- powershell.exe -EncodedCommand <base64> obfuscates commands from simple string-matching detection; the encoding itself is a malicious indicator requiring context to confirm.
- Privilege escalation: new admin account creation
- net user /add followed by net localgroup administrators /add after initial compromise indicates privilege escalation; correlate with the user context that ran the commands.
- Command and Control: beaconing pattern
- Regular outbound connections to the same external IP at consistent intervals (every 60s, 300s) indicates C2 beaconing; 47 connections to unique IPs in 5 minutes suggests C2 callback spray.
Key Exam Distinctions and Common Traps
- top() already aggregates — do NOT add groupBy() before it
- Adding groupBy before top() is redundant; top() performs counting and ranking in a single step — this is a direct exam trap.
- First-party detections > third-party for initial triage
- When multiple detection types exist for the same host, first-party CrowdStrike EDR detections provide richer context (process tree, user, TI enrichment) than third-party passthrough alerts.
- CCSA uses SOAR; CCSE builds SOAR
- The CCSA exam tests whether analysts can UTILIZE existing Falcon Fusion SOAR workflows for containment; building and configuring workflows is the CCSE (engineer) exam scope.
- Lateral movement ≠ Privilege escalation
- Lateral movement = spreading ACROSS systems horizontally; privilege escalation = gaining HIGHER access ON one system — both post-compromise but serve different attacker objectives.
- Severity ≠ Confidence
- High severity + low confidence = potentially serious but uncertain — investigate to validate, do not immediately escalate or dismiss; both dimensions required for triage.
- IOC ≠ IOA
- IOCs are static known-bad artifacts (reactive); IOAs are behavioral patterns of attack in progress (proactive) — Falcon native detections are IOA-based, enrichment uses IOCs.
- CPS source.ip ≠ vendor-specific src_ip
- CPS normalized fields work across all data sources; raw vendor fields only exist in specific source logs — always use CPS fields when writing cross-source queries.
- 80% passing threshold — 12 errors maximum
- With 60 questions, you can miss at most 12; Incident Investigation (40%) and Querying and Analytics (25%) must be mastered first given their combined 65% weight.