How I Detected and Fixed a Shellshock Attack on a Linux Server

Incident Overview

The production server hosted in a Shanghai data center became unresponsive; a remote reboot failed and the service could not start. Initial suspicion turned to a possible compromise when a ransom note appeared in /etc/motd demanding Bitcoin payment.

Investigation Steps

Using a systematic log‑review approach, the author executed a series of commands to locate suspicious files, altered permissions, and potential backdoors:

find / -type f -perm 4000

rpm -Vf /bin/ls

rpm -Vf /usr/sbin/sshd

grep -r "getRuntime" ./

find . -type f -name "*.jsp" | xargs grep -i "getRuntime"

Additional searches for common web‑shell signatures ( getHostAddress, wscript.shell, jspspy, etc.) and unauthorized log entries were performed with fgrep patterns such as "and1=1", "select", and "union". System logs ( /var/log/secure, /var/log/cron, /var/log/wtmp) were examined for abnormal activity, and temporary directories ( /tmp, /var/tmp) were listed for leftover files.

Ransom Note Discovery

The /etc/motd file contained repeated lines like:

Hi, please view: http://pastie.org/pastes/10800563/text?key=hzzm4hk4ihwx1jfxzfizzq for further information in regards to your files!

indicating that the attacker had already deleted many logs and was demanding payment.

Identifying the Shellshock Exploit

Further analysis of web access logs revealed a suspicious request: GET /cgi-bin/center.cgi?id=20 HTTP/1.1 Testing the server with the classic Shellshock payload confirmed the vulnerability:

env x='() { :;}; echo vulnerable' bash -c "echo this is a test"

The command output showed "vulnerable", proving that the Bash version was exploitable.

Mitigation and Patch

The author installed chkrootkit to verify the absence of rootkits, then upgraded Bash using yum:

yum -y install yum-downloadonly

yum -y install bash-4.1.2-33.el6_7.1.x86_64.rpm

The upgrade process completed successfully, and a retest of the payload no longer displayed "vulnerable".

Post‑Compromise Hardening

Changed all system account passwords.

Moved SSH daemon to a non‑standard port (2220).

Set the Nginx user to nologin.

Confirmed the Shellshock vulnerability was patched.

Monitored the server after the update and observed no further crashes or intrusion signs.

Shellshock Background

Shellshock (also known as Bashdoor) is a critical vulnerability disclosed on 24 September 2014 that allows arbitrary code execution in Bash when specially crafted environment variables are processed. Many internet‑facing services invoke Bash, making the flaw a high‑impact vector for remote code execution.

By identifying the exploit, applying the Bash patch, and tightening system configurations, the author restored service stability and reduced the attack surface.