Vulnhub: Aragog (HackingHP)

Aragog (a Harry Potter-themed box) is a clean mirror of a real engagement: a vulnerable WordPress plugin for entry, credential reuse from a looted database, and a writable root-run backup script to finish. Every step is the natural consequence of the last, which is exactly how web-to-root compromises unfold in practice.

Attack chain at a glance

Recon — only SSH (22) and HTTP (80); directory scanning shows the site is WordPress.
Foothold — a Metasploit scan flags the wp-file-manager plugin; the public exploit uploads a PHP reverse shell (an authenticated/unauth arbitrary file upload → RCE) landing a shell as www-data; first flag under hagrid98.
Loot — linpeas recovers database credentials; the WordPress users table holds hagrid98's password hash, cracked with John to password123.
Lateral — reuse those creds to become hagrid98 (and switch to SSH).
Root — pspy reveals a root-run backup script that is world-writable; inject a reverse shell into it and catch root on the next scheduled run; second flag.

Techniques in play: WordPress enumeration (Metasploit's wpscan auxiliary), a known-plugin file-upload exploit, database looting and credential reuse, and the single most common Linux privesc after sudo — a writable file executed by a privileged scheduled task, found with pspy (process monitoring without root).

Aragog (a Harry Potter-themed box) runs a WordPress site with a vulnerable File Manager plugin for the foothold, leaks database credentials that crack a user's WordPress hash, and finishes with a writable, root-run backup script for the root shell.

Reconnaissance

Aragog VM booted from Vulnhub — The Aragog VM running.

netdiscover finds the target at 192.168.0.107.

netdiscover showing the target IP — Target located at `192.168.0.107`.

nmap shows only SSH (22) and HTTP (80) open.

nmap results showing ports 22 and 80 open — A small surface: SSH and HTTP.

Port 80 just serves an image, so a nikto scan digs deeper.

The web page showing only an image — Nothing obvious on the web root.

nikto scan against port 80 — A `nikto` scan of the service.

It surfaces a login.php page, noted for later.

login.php discovered by nikto — A `login.php` worth remembering.

A directory scan confirms the site runs WordPress.

Directory scan revealing a WordPress install — The site is WordPress.

Foothold: WordPress File Manager

In msfconsole, the WordPress auxiliary scanner is pointed at the host with RHOSTS and TARGETURI set.

Metasploit WordPress scanner configured and run — Scanning the WordPress install with Metasploit.

It detects the wp-file-manager plugin, so Exploit-DB is checked for a matching exploit.

wp-file-manager plugin detected — The vulnerable `wp-file-manager` plugin.

There is a public exploit that uploads a file via the plugin; it is downloaded.

Exploit-DB page for the wp-file-manager vulnerability — The matching exploit on Exploit-DB.

Fetching the exploit from GitHub — Grabbing the exploit from GitHub.

Running it with --check confirms the target is vulnerable.

Exploit --check confirming the target is vulnerable — `--check` reports the target exploitable.

A PHP reverse shell is fetched to upload through the plugin.

Downloading a PHP reverse shell — A PHP reverse shell payload.

The callback IP is set to Kali and the port to 5555.

Editing the reverse shell with the Kali IP and port 5555 — Pointing the shell at Kali on port 5555.

The exploit uploads the shell and returns its URL; opening that URL against a waiting listener on 5555 catches the connection.

Running the exploit to upload the reverse shell — Uploading the shell via the plugin.

netcat listener on port 5555 — A listener waiting on 5555.

The shell lands as www-data.

Reverse shell received as www-data — Foothold as `www-data`.

Under /home, a hagrid98 folder holds horcrux1 — the first flag.

horcrux1 file containing the first flag — `horcrux1`: the first flag.

Looting the database

To escalate, linpeas is staged from Kali with SimpleHTTPServer and wget (curl isn't available on the target), made executable, and run.

Making linpeas executable and running it — linpeas staged and run on the target.

It recovers database credentials, which are used against MySQL.

Database credentials found by linpeas — WordPress database credentials from linpeas.

On this box the MySQL client only flushed its output on exit, so each query was run in a separate session — slower, but it gets the data out.

Listing the MySQL databases — Enumerating the databases.

Within the wordpress database, the tables are listed.

Listing tables in the wordpress database — Tables in the `wordpress` schema.

The users table holds a WordPress hash for hagrid98.

wp_users row with hagrid98's password hash — `hagrid98`'s stored password hash.

John cracks it against rockyou to password123.

John cracking the hash to password123 — The hash cracks to `password123`.

Privilege escalation

Those credentials switch to hagrid98…

Switching to the hagrid98 user — `su hagrid98` succeeds.

…and the same password works over SSH for a stable session.

Reconnecting as hagrid98 over SSH — A proper SSH session as `hagrid98`.

linpeas again shows nothing obvious, so pspy is used to watch processes without root.

Running linpeas again as hagrid98 — A second linpeas pass — nothing new.

Downloading pspy to monitor processes — Staging `pspy`.

pspy monitoring running processes — Watching processes with `pspy`.

pspy shows a root-run script that performs a backup — and it is writable.

pspy revealing a root-run writable backup script — A backup script running as root on a schedule.

A reverse-shell line is appended to the script and saved; the next scheduled run executes it as root.

Appending a reverse shell to the backup script — Injecting a reverse shell into the writable script.

A listener on the matching port catches the root callback.

Root reverse shell received on the listener — The script fires and calls back as **root**.

In /root sits horcrux2.txt — the second flag, and the box.

horcrux2.txt root flag completing the box — `horcrux2.txt`: the final flag.

Aragog is a clean mirror of a real engagement: a vulnerable plugin for entry, credential reuse from a looted database, and a writable root cron/backup script to finish — each step the natural consequence of the last.

Defender's notes

Keep WordPress core and plugins patched — wp-file-manager had a critical unauthenticated file-upload RCE (file upload).
Don't reuse the database/application password for an OS account; rotate and segregate credentials.
Any script run by root on a timer must be owned by root and writable only by root — a world-writable cron/backup script is a direct root primitive.
Store WordPress hashes you can't avoid exposing behind strong policy; password123 falls to rockyou instantly.