Shellshock Attack

Scenario

Analysis of shellshock attack

Executive Summary

An attacker sent a single crafted HTTP request to a CGI script on an Apache web server. The request abused the Bash function-definition parsing flaw (Shellshock) by placing a malicious function prefix in the User-Agent header, which the CGI environment passed straight to Bash. The payload was a connectivity probe back to an attacker-controlled host rather than a full shell, so the capture shows reconnaissance-style proof of code execution and nothing further.

Artifacts

• Packet capture: shellshock.pcap → open with tshark or Wireshark. One HTTP exchange is all there is to read

Initial Access

The HTTP response carries the fingerprint. Pull the response headers and read the Server field, which appends the OS in parentheses after the Apache banner.

tshark -r shellshock.pcap -Y http.response -T fields -e http.server

Same Server header as Q1. The product and version come before the OS in parentheses, and the answer follows the format hint of name, slash, version.

tshark -r shellshock.pcap -Y http.response -T fields -e http.server

Tip: Submit the product and version only, without the OS tag in parentheses.

Execution

Look at the request, not the response. The target URI is a .cgi script, and the User-Agent starts with () { :;};, the Shellshock function-definition prefix. Bash parses that as a function and then executes whatever follows it, so the text after the prefix is the injected command. It is a single ICMP echo to an attacker-side address, which would confirm execution without needing a reverse shell.

tshark -r shellshock.pcap -Y http.request -T fields -e http.request.uri -e http.user_agent

Hint: The payload sits entirely in the header value after () { :;};. Copy it exactly, including the flags and spacing.

Attack Summary

Phase	Action
Initial Access	HTTP request to an exploitable CGI script on an Apache 2.2.22 server
Execution	Shellshock payload in the User-Agent header runs a single ping toward 10.246.50.2

IOCs

Type	Value
IP (ping target in payload)	10.246.50[.]2
Header payload	() { :;}; /bin/ping -c1 10.246.50.2
Target script	/exploitable.cgi

MITRE ATT&CK

Technique	ID	Description
Exploit Public-Facing Application	T1190	Shellshock delivered to a CGI script over HTTP
Command and Scripting Interpreter: Unix Shell	T1059.004	Injected command executed by Bash on the server

Defender Takeaways

Bash behind CGI turns every request header into a command-injection surface. CGI copies headers into environment variables, so an unpatched Bash executes whatever follows a function definition in User-Agent, Cookie or Referer. Patch Bash, and retire CGI scripts that shell out when there is no need for them.

() { in an HTTP header is a reliable signature. Legitimate clients never send a function-definition prefix in a header. A WAF or IDS rule on () { in any request header catches the whole Shellshock family regardless of the payload that follows.

A single ping is a probe, so treat it as the start. The attacker only tested for execution. Egress ICMP from the web server to an unexpected host is an alert on its own, and it tells you which servers are exploitable before a real payload arrives.

Server banners hand the attacker the patch level. The Server header disclosed the product, version and OS in one line. Trim it with ServerTokens Prod so the response stops advertising the stack.

Conclusion

The attacker proved remote command execution on an Ubuntu Apache server with one request and one ping. The capture contains no follow-up, but a header starting with () { is all it takes to find and confirm a vulnerable host.