HTB: PiHole | securitea.tech

Overview

PiHole is a deceptively simple box that teaches an important lesson: the obvious attack surface is not always the right one. The Pi-hole admin panel dominates the enumeration phase. It has a login form, API endpoints, and a potential command injection surface in queryads.php. None of it works. The actual entry point is the operating system beneath the application: default Raspberry Pi SSH credentials that were never changed.

The privilege escalation is trivial (passwordless sudo for everything), but the root flag introduces a forensic recovery challenge. The flag was deleted from a USB stick, and recovering it requires reading raw block device data. The box rewards pragmatism over complexity.

Reconnaissance

The target blocks ICMP, so host discovery requires -Pn:

nmap -Pn -sV -sC -p- --min-rate 5000 10.129.14.196

Port	Service	Product / Version	Notes
22	SSH	OpenSSH 6.7p1 Debian	Raspbian-era OpenSSH
53	DNS	dnsmasq 2.76	DNS forwarder for Pi-hole
80	HTTP	lighttpd 1.4.35	Pi-hole admin interface

Three services. The SSH version string (Debian) and the lighttpd server combined with Pi-hole point to a Raspberry Pi running Raspbian. The DNS service is dnsmasq, the backend resolver that Pi-hole wraps.

Attack Surface Analysis

Pi-hole admin panel

lighttpd serves a Pi-hole v3.1.4 installation at /admin/. The login form accepts a single password field (no username). I test 14 common defaults: pihole, raspberry, admin, password, 1234, and variations. All return HTTP 401.

The unauthenticated API at /admin/api.php returns statistics (queries today, blocked percentage, top domains) but nothing exploitable. No credentials, no internal paths.

queryads.php command injection surface

queryads.php accepts a domain parameter and shells out to query Pi-hole’s blocklist. The domain input is validated against a strict FQDN regex before execution. Special characters, whitespace, and encoding tricks are all rejected. The filter is adequate; this is a dead end.

Pi-hole v3.1.4 CVE research

Pi-hole v3.1.4 has no known unauthenticated RCE. The web surface requires valid credentials for any administrative action, and I do not have them.

Vulnerability Analysis

The actual vulnerability is not in Pi-hole at all. Raspberry Pi ships with a default user pi and password raspberry. Pi-hole is overwhelmingly deployed on Raspberry Pi hardware, and operators frequently never change the OS-level credentials. The HTB box mimics this real-world pattern exactly.

Attribute	Value
CWE	CWE-1393 (Use of Default Credentials)
Root cause	Raspberry Pi default password unchanged
Impact	Full system access via SSH

This is not a software vulnerability in the traditional sense. It is a deployment misconfiguration that is so common in IoT and home-lab environments that it might as well be a vulnerability class of its own.

Exploitation

Initial access

ssh [email protected]
# Password: raspberry

Login succeeds. The Pi-hole application, its admin panel, and its queryads.php injection surface were all irrelevant. The entry point is the operating system.

cat /home/pi/Desktop/user.txt

User flag captured.

Privilege escalation

sudo -l

User pi may run the following commands on localhost:
    (ALL : ALL) NOPASSWD: ALL

The pi user has unrestricted passwordless sudo. This is the Raspbian default and is commonly left unchanged:

sudo su -

Root shell obtained.

Root flag recovery

The root flag is not at the standard location. Instead, /media/usbstick/ contains a single file:

cat /media/usbstick/damnit.txt

Damnit! Sorry man I accidentally deleted your files off the USB stick.
Do you know if there is any way to get them back?

-James

The device /dev/sdb is a 10 MB ext4 filesystem. The flag was deleted, but on a small, mostly idle block device, the data blocks are almost certainly still present on disk. The filesystem just no longer references them.

Full forensic recovery tools (extundelete, photorec) would work, but on a device this small, strings against the raw block device is faster and sufficient:

sudo strings /dev/sdb | grep -E "^[a-f0-9]{32}$"

This pipes the raw bytes through strings to extract printable sequences, then filters for exactly 32 lowercase hex characters: the MD5 hash format HTB uses for flags. The deleted inode’s data blocks are still on disk.

Root flag captured.

Alternative recovery methods

For completeness, two other approaches would work on this device:

extundelete: recovers files by scanning the filesystem journal for recently deleted inodes. On ext4, deleted inodes retain their block pointers in the journal for a period after deletion. This is the “proper” forensic approach and works even when strings would fail (binary data, non-printable content).

sudo extundelete /dev/sdb --restore-all

photorec: a file carver that scans raw blocks for known file signatures (headers and footers). It ignores the filesystem entirely and works across filesystem types. Overkill for a 32-character text string, but essential for recovering structured files (images, documents, databases).

The reason strings | grep is sufficient here is that the target is a predictable format (32 hex characters on a line by itself) and the device is small enough that false positives are manageable. On a production disk with gigabytes of data, the false positive rate would make this approach impractical.

Post-Exploitation

In a real engagement, the post-exploitation analysis for this host would focus on the broader network impact of a compromised DNS server:

DNS poisoning: Pi-hole controls DNS resolution for all clients configured to use it. A compromised Pi-hole can redirect any domain to an attacker-controlled IP.
Credential harvesting: DNS query logs reveal which domains are being accessed, providing intelligence for targeted attacks.
Lateral movement: The Pi typically sits on the same network segment as all client devices. SSH keys and network credentials on the Pi may provide access to other hosts.
Persistence: Modifying the blocklist or DNS configuration provides a persistent man-in-the-middle position.

Defensive Analysis

Detection opportunities

Phase	MITRE ATT&CK	Detection
Initial access	T1078.001	SSH login with default credentials (failed login audit)
Privilege escalation	T1548.003	sudo to root from pi user
Collection	T1005	Reads of raw block devices by non-backup processes
Persistence	T1565.001	DNS configuration modifications

Network-level: SSH brute-force and default credential attempts should be detected by fail2ban or equivalent. A single successful login with default credentials after deployment indicates the password was never changed.

Host-level: The pi user should not have passwordless sudo in any production deployment. If sudo is required, restrict it to specific commands. Any strings or dd operation against block devices outside of backup windows is suspicious.

Remediation

Priority	Action	Effort	Impact
P0	Change the default pi password	Low	Critical
P0	Remove NOPASSWD ALL from sudoers for pi	Low	Critical
P1	Set a Pi-hole admin password	Low	High
P1	Disable SSH password authentication (use keys)	Low	High
P2	Deploy fail2ban for SSH brute-force protection	Low	Medium
P2	Use full-disk encryption on removable media	Medium	Medium
P3	Monitor for raw block device access	Low	Low

The deeper issue is that Raspberry Pi and similar IoT/appliance platforms ship with known default credentials and permissive sudo configurations. Operators deploy Pi-hole for its DNS filtering capability and never touch the underlying OS security. Every Raspberry Pi with unchanged defaults is a root shell waiting for anyone who tries pi:raspberry.

For deleted file recovery, the defence is encryption. If the USB stick used LUKS or equivalent full-disk encryption, strings against the raw device would return nothing useful. Encryption at rest prevents data recovery after deletion.

Key Takeaways

The obvious attack surface is not always the right one. The Pi-hole admin panel dominates the enumeration phase, but the entry point is the operating system beneath it. Spending time on web exploitation here is the intended rabbit hole.
Default credentials are the most reliable exploit. No buffer overflow, no CVE, no complex chain. pi:raspberry is the fastest path to root on thousands of Raspberry Pi deployments worldwide.
strings on raw block devices recovers deleted data. On small, idle filesystems, deleted file data persists until overwritten. strings | grep is faster than full forensic recovery suites when the target format is known.
Passwordless sudo is root access with extra steps. The Raspbian default of NOPASSWD: ALL for the pi user means any compromise of the pi account is immediate full root. There is no privilege boundary.
Compromised DNS is a network-wide threat. A Pi-hole compromise gives the attacker control over DNS resolution for every device using it. The blast radius extends far beyond the Pi itself.