CSA (312-39) SOC Simulation Lab

In this lab, you'll learn how to trace automated scanning and scraping activities. We will analyze the OSI layer limitations of different log sources to pinpoint exactly where malicious HTTP headers are recorded in a real SOC environment.

Scenario Context

You are an L2 Analyst monitoring the perimeter for "RetailCore", an e-commerce platform hosted in AWS. Recently, the marketing team reported severely skewed web analytics, and the DevOps team noted that database CPU usage has spiked by 40% during off-peak hours.

You suspect automated scraping or brute-forcing activity targeting the product API and login endpoints. You need to pull the correct logs into your SIEM (Splunk) to build a detection query for these automated tools.

Security Environment

You have access to a centralized logging infrastructure. A quick raw search in the SIEM reveals the following snippet associated with the suspected attack window:

192.168.1.100 - - [08/Apr/2026:02:15:22 +0000] "GET /api/v1/products?id=1' OR '1'='1 HTTP/1.1" 403 512 "-" "sqlmap/1.8.2#dev (https://sqlmap.org)"
203.0.113.45 - - [08/Apr/2026:02:15:24 +0000] "POST /login HTTP/1.1" 401 128 "-" "python-requests/2.28.1"
104.21.55.12 - - [08/Apr/2026:02:15:25 +0000] "GET /catalog/hidden HTTP/1.1" 404 256 "-" "masscan/1.3 (https://github.com/robertdavidgraham/masscan)"

*Review the terminal output above to determine which infrastructure component generated this specific log format.*

Question

Which of the following data source can be used to detect the traffic associated with Bad Bot User-Agents?

SOC Hint: The "User-Agent" is an HTTP header. HTTP operates at Layer 7 (Application) of the OSI model. Which of the options natively processes and logs Layer 7 web traffic requests?

Expert Insight

What is happening?

The SOC is hunting for automated malicious software (bots). When a bot connects to a server, it sends an HTTP request. Part of that request is the User-Agent header, which tells the server what client software is being used (e.g., Mozilla Firefox, curl, python-requests). Attackers frequently fail to change default User-Agents in their scripts, making them highly visible.

Why Option B is Correct:

Web Servers (like Nginx, Apache, or IIS) are Layer 7 applications. They natively terminate HTTP connections, parse the HTTP headers, and write the details—including the Source IP, HTTP Method, URI, Status Code, and the User-Agent—directly into their access logs. This makes Web Server logs the primary data source for hunting malicious User-Agents.

Why the others are wrong:

  • C & D (Router / Switch Logs): Routers operate at Layer 3 (IP) and Switches at Layer 2 (MAC). While they handle the network packets, they do not perform Deep Packet Inspection (DPI) to extract Layer 7 HTTP headers by default. They log NetFlow (source/dest IP, ports, bytes), but not User-Agents.
  • A (Windows Event Logs): While excellent for endpoint telemetry (Process Creation - 4688, Logons - 4624), standard Windows Event Logs do not natively capture inbound HTTP headers. Even if the web server is IIS on Windows, the HTTP traffic is logged in IIS access logs (W3C format), not the core Windows Application/System/Security event logs.

🛡️ SOC Mini-Lesson: Advanced User-Agent Hunting

In a real-world SIEM environment (like Splunk or Sentinel), searching for known bad User-Agents like sqlmap or Nmap Scripting Engine is a solid L1 tactic. However, advanced attackers will spoof their User-Agent to look like a standard Google Chrome browser.

How do Senior Analysts catch them?

We use correlation and baselining. We look for:

  • Anomalous Volume: A single IP making 5,000 requests per minute with a generic Windows/Chrome User-Agent. A human can't click that fast.
  • JA3/JA4 Hash Mismatches: Every client has a unique TLS handshake signature (JA3 hash). If the User-Agent claims to be "Chrome 120" but the JA3 hash matches a Python library, the traffic is spoofed and highly suspicious.

Ready to sharpen your defensive skills further?

Explore more CSA simulations