CSA (312-39) SOC Simulation Lab

Learn how to interpret HTTP status codes during web traffic analysis and identify potential protocol smuggling or WebSocket-based C2 channels bypassing your WAF.

Scenario Context

You are a Tier 3 SOC Analyst reviewing an escalation from a L1 analyst. A generic anomalous bandwidth alert fired on an external-facing DMZ web server (SRV-DMZ-WEB-04). The L1 analyst notes that the Web Application Firewall (WAF) isn't blocking the traffic, and the HTTP status codes returned by the server are in the 1xx range, rather than the expected 200 OK.

The L1 analyst asks you: "The server is responding with a 101 status code, and then the connection stays open for hours transferring gigabytes of data. Did the request fail, or what does this code mean?"

Security Environment

You pull the raw proxy logs from the WAF into Splunk to observe the initial HTTP handshake causing the alert.

[18:22:10] src_ip=203.0.113.45 dest_ip=10.10.5.44 http_method=GET uri="/app/updates" http_user_agent="Mozilla/5.0"

[18:22:10] request_headers: "Host: portal.acmecorp.com | Connection: Upgrade | Upgrade: websocket | Sec-WebSocket-Version: 13"

[18:22:11] http_status=101 http_response="Switching Protocols"

[19:45:00] session_duration=4970s bytes_in=45MB bytes_out=1.2GB action=allowed

To accurately assess whether this is normal behavior or an active Command and Control (C2) session, you must first understand the fundamental classification of the HTTP status code provided by the server.

Question

What does the HTTP status codes 1XX represents?
A. Informational message
B. Client error
C. Success
D. Redirection
SOC Hint: Think about the structure of HTTP status codes. 200s mean things went well, 400s mean the client messed up (like a 404), and 500s mean the server crashed. What does the very first block (100-199) indicate before the final request is processed?

Expert Insight

1. What is happening?

The adversary is establishing a bidirectional communication channel over WebSockets. They initiate a standard HTTP GET request but include the Upgrade: websocket header. The server agrees to this change by sending an HTTP 101 Switching Protocols response. Once this happens, the protocol shifts from HTTP to WebSockets. Because it's no longer standard HTTP, many legacy WAFs and proxies stop inspecting the payload, allowing the attacker a clear, uninspected Command & Control (C2) tunnel.

2. Why A is correct

1xx codes are Informational. They indicate that the server has received the request and the process is continuing. A 101 Switching Protocols doesn't mean the request is fully completed (like a 200 OK); it merely informs the client that the server acknowledges the request to change the application protocol (e.g., from HTTP/1.1 to WebSockets or HTTP/2).

3. Why the others are wrong

  • B. Client Error (4xx): These codes (like 400 Bad Request, 403 Forbidden, 404 Not Found) mean the request was syntactically incorrect or cannot be fulfilled.
  • C. Success (2xx): These codes (like 200 OK, 201 Created) mean the action was successfully received, understood, and accepted.
  • D. Redirection (3xx): These codes (like 301 Moved Permanently, 302 Found) mean further action must be taken by the client to complete the request.

4. Real-world SOC Application

While 1xx codes are "informational" by definition, in a SOC environment, an unexpected HTTP 101 to a server that isn't explicitly configured to host WebSocket applications (like a chat server or live-trading app) is a massive red flag. Attackers use frameworks like Sliver, PoshC2, and Cobalt Strike configured with WebSocket profiles to blend in with normal web traffic. As a SOC analyst, you must map the status code to the context of the session duration and byte counts.

MINI LESSON: Hunting for Protocol Smuggling/WebSocket C2

When threat hunting in your SIEM, you shouldn't just look for 404 errors or 500 errors. You need to identify abnormal continuous connections that disguise themselves via informational status codes.

# Splunk Query to detect potential WebSocket C2 via 101 Status Codes

index=proxy OR index=firewall sourcetype=pan:traffic

| search http_status="101" AND action="allowed"

| stats sum(bytes_in) as TotalIn, sum(bytes_out) as TotalOut, avg(session_duration) as AvgDuration by src_ip, dest_ip, uri

| where AvgDuration > 3600 AND TotalOut > 10000000

Pro-Tip for ExamRange users: If a Web Application Firewall cannot inspect the upgraded protocol, recommend implementing SSL Decryption at the Next-Gen Firewall layer and utilizing Application ID (App-ID) to explicitly block unapproved `websocket` traffic to specific DMZ zones.

Ready for the next incident?

Enhance your detection engineering and incident response skills.

Explore more CSA simulations