CSA (312-39) SOC Simulation Lab

In this lab, you will apply the Cyber Threat Intelligence (CTI) lifecycle to a real-world scenario. Learn how analysts structure their investigations when dealing with evasive malware communicating via Domain Generation Algorithms (DGAs).

Scenario Context

During a routine threat hunt within Splunk, a Tier 3 CTI Analyst notices an endpoint generating hundreds of DNS queries to randomly generated, non-existent domains. Existing static IOC (Indicators of Compromise) feeds are failing to detect this because the malware uses a DGA, meaning the C2 domains change every few hours. Before building a new detection rule, the analyst pauses to define exactly what telemetry is missing and what questions need to be answered to track this specific threat actor.

Security Environment

Analyst's Splunk SPL Query & Output (Identifying the DGA Behavior):

> index=network sourcetype=stream:dns reply_code="NXDOMAIN" | stats count by src_ip, query | where count > 50 [Results - Timeframe: Last 60 minutes] src_ip: 10.50.14.22 query: xkqj1293[.]com count: 52 src_ip: 10.50.14.22 query: zpxo991[.]net count: 55 src_ip: 10.50.14.22 query: mnbc8821aa[.]org count: 51

Analyst Note: High volumes of NXDOMAIN (Non-Existent Domain) responses to high-entropy strings are a classic indicator of a DGA attempting to find its active C2 server.

Question

A security analyst working in a multinational corporation's Threat Intelligence team is tasked with enhancing the organization's ability to detect stealthy malware infections. During an investigation, the analyst observes an unusually high volume of DNS requests directed toward domains that follow patterns commonly associated with Domain Generation Algorithms (DGAs). Recognizing that these automated domain queries could indicate a malware strain attempting to establish communication with its Command & Control (C2) infrastructure, the analyst realizes that existing detection capabilities may not be sufficient. To effectively counter such threats, the security team needs to define intelligence requirements—including identifying critical data sources, refining detection criteria, and improving threat monitoring strategies.

Which stage of the Cyber Threat Intelligence (CTI) process does this scenario align with?

Analyst Hint: Look at the keywords: "define intelligence requirements" and "identifying critical data sources". In the standard threat intelligence lifecycle (Direction/Requirements, Collection, Processing, Analysis, Dissemination, Feedback), which phase involves setting the goals before collecting the data?

Expert Insight

1. What is Happening

The SOC has encountered a threat (DGA malware) that bypasses traditional, signature-based defenses (like static IP/Domain blocklists). Instead of blindly guessing what to do next, the analyst is initiating the Cyber Threat Intelligence (CTI) lifecycle. They are determining what specific information is needed (e.g., DNS telemetry, EDR process logs) to build a robust, behavioral detection mechanism.

2. Why Option B is Correct

Requirement Analysis (often called Direction or Planning & Direction) is the foundational first step of the CTI lifecycle. In this scenario, the security team is actively "defining intelligence requirements," "identifying critical data sources," and "refining detection criteria." They are setting the objectives for what intelligence needs to be collected and processed to solve a specific security gap (detecting DGAs).

3. Why the Other Options are Wrong

A (Intelligence Buy-In): While gaining stakeholder support is important, it is a business/management concept, not a formal phase of the technical CTI lifecycle.
C (Automated tool): Automation is a capability or method used during Collection or Processing; it is not a phase of the intelligence cycle itself.
D (Filtering CTI): Filtering and structuring data occurs during the Processing phase. You cannot filter data until you have defined your requirements and actually collected the raw logs.

Mini Lesson: SOC Triage for DGA (Domain Generation Algorithms)

When malware uses a DGA, it generates thousands of domains daily to find its C2 server. Most of these domains won't be registered, resulting in a DNS NXDOMAIN (RCODE 3) error.

How to hunt it:
1. Volume Spike: Look for internal endpoints generating an abnormally high ratio of NXDOMAIN errors compared to successful resolutions (NOERROR).
2. Shannon Entropy: Modern SIEMs can calculate the randomness (entropy) of a string. "google.com" has low entropy. "xkqj1293zpx.com" has high entropy.
3. EDR Pivot: Once you identify the infected IP (e.g., 10.50.14.22), pivot to your EDR tool (like CrowdStrike or Defender). Query for the specific process that initiated those high-entropy DNS requests. It is often a legitimate process injected by malware (e.g., svchost.exe or explorer.exe making unusual network calls).

Looking to master more SOC scenarios and exam topics?

Explore more CSA simulations