CSA (312-39) SOC Simulation Lab
Welcome to the Tier 3 analysis queue. In this module, you will analyze firewall telemetry to determine how perimeter controls are configured to prevent internal threats from communicating externally. Master this to prevent data exfiltration and C2 beaconing.
Scenario Context
You are investigating a potentially compromised legacy database server (`10.10.50.22`). The EDR agent on the server has been disabled, leaving you blind to the endpoint processes. However, a high-severity alert triggered in the SIEM based on the perimeter Next-Generation Firewall (NGFW) logs.
The server appears to be executing an automated script, attempting to reach a known malicious IP address associated with a Cobalt Strike Team Server.
Security Environment
Review the raw syslog output forwarded from the perimeter firewall to your Splunk indexer:
fw-perim-01 CEF:0|Palo Alto Networks|PAN-OS|10.1.5|Traffic|drop|4|rt= src=10.10.50.22 spt=54113 dst=185.150.x.x dpt=4444 proto=tcp action=Deny rule=Block-All-Outbound-Except-Proxy app=unknown-tcp
Question
Which of the following technique involves scanning the headers of IP packets leaving a network to make sure that the unauthorized or malicious traffic never leaves the internal network?
Expert Insight
What is happening here?
An internal server (`10.10.50.22`) has been compromised and is attempting to establish a reverse shell connection (tcp/4444) to an external attacker infrastructure (`185.150.x.x`). However, because the perimeter firewall is configured with a strict "Default Deny" policy for outbound traffic (as seen by the rule Block-All-Outbound-Except-Proxy), the connection is dropped. The attacker is trapped inside the network and cannot establish Command & Control (C2).
Why 'A' is correct
Egress Filtering specifically refers to the practice of monitoring and potentially restricting the flow of information outbound (leaving) from one network to another. In a SOC, egress filtering prevents exfiltration, blocks C2 communications, and prevents internal devices from participating in DDoS amplification attacks via IP spoofing (e.g., verifying that the source IP of a leaving packet actually belongs to the internal subnet).
Why the others are wrong
B. Throttling / C. Rate Limiting: These involve shaping network traffic to control the rate of requests (e.g., stopping a brute-force attack or managing bandwidth). They do not explicitly focus on scanning packet headers to block unauthorized outbound destinations based on security policies.
D. Ingress Filtering: This is the opposite. Ingress filters scan packets entering the network to block unauthorized external traffic from coming in. If we were blocking an attacker scanning our public web server from the outside, that would be ingress filtering.
MINI LESSON: The "Zero Trust" Outbound Strategy
A common mistake junior network engineers make is securing incoming traffic (ingress) perfectly while leaving outbound traffic (egress) fully open (e.g., Allow Any to Any outbound). This is a critical vulnerability.
Best Practice SOC Architecture: Endpoints should never be allowed to communicate directly with the internet on any port. All web traffic (HTTP/HTTPS) should be forced through a Secure Web Gateway (SWG) or Proxy, which inspects the traffic for malware. DNS traffic should only be allowed outbound from internal DNS servers, not workstations. If you see an endpoint making a direct outbound connection to the internet over a non-standard port (like 4444 or 6667) in your SIEM, it is almost certainly a compromised host beaconing out.
Ready to test your SOC detection logic further?
Explore more CSA simulations