Internal Pentest: Five Boxes, Five Ways In
This is a retrospective on an internal penetration test I ran as the final for a CMIS offensive-security course. The scope was five intentionally-vulnerable hosts on one flat network, assessed end to end from enumeration through root. On four of the five boxes, the way in was a configuration problem, not a software flaw. Each section is the shortest honest path to root/admin, then the fix that would have stopped it.
Approach
The approach was standard for an internal test. I enumerated services on every host, identified the software and versions, researched known issues, then exploited the shortest path to administrative access. Nmap with service and version detection and default scripts drove discovery. After that each box diverged.
The network was a single flat /24 with no segmentation between hosts, which is
itself the first finding. On a real network, lateral movement between unrelated
services shouldn’t be free.
Host 1: Nagios XI (RCE via default credentials)
Web enumeration turned up a Nagios XI monitoring console. Directory brute-forcing found little, so the quicker route was the login page itself. The install shipped with default administrative credentials that had never been changed.
With an authenticated admin session, the running version was old enough to be vulnerable to a well-documented authenticated remote command execution issue (CVE-2019-15949, CVSS 8.8). The published exploit runs commands as root, so there was no privilege escalation step.
Fix: Change default credentials before a service is ever reachable, and keep Nagios XI patched past the fixed release.
Host 2: Windows / SMB (guest access and credentials in a file)
A Windows host exposed SMB and RDP. SMB allowed guest access, and guest could read several shares it had no business reading. Walking those shares turned up an unattended-install answer file with an Administrator username and a password stored in it, “encrypted” only in the sense that it was Base64-encoded, which is encoding, not encryption.
Decoding gave working Administrator credentials. RDP was open, so those credentials logged straight in as a domain administrator.
Fix: Three independent failures line up here, and closing any one stops the chain. Disable SMB guest access, lock share permissions down to who actually needs them, and never store credentials in files (Base64 is not protection). Defence in depth means an attacker has to beat all three, not just one.
Host 3: LazySysAdmin-style Linux (plaintext password in a web root)
Port 80 served a WordPress-ish site whose posts leaked a likely username. SMB again allowed guest read, and a file in an open share contained a note with a plaintext password and a candid “remember to remove this before we ship” comment, which, of course, no one did.
That username and password worked over SSH for a user shell. The user was in the
sudo group, so sudo su with the same weak password returned root immediately.
Fix: Don’t publish usernames, don’t leave credentials in world-readable shares,
and don’t hand sudo to an account whose password is five digits. Each of those
alone would have blunted the attack.
Host 4: Fowsniff (public breach dump to mail to kernel exploit)
The web root advertised that the company had been breached and its credentials dumped publicly, and the dump really was reachable. The hashes cracked easily, where salting and a strong algorithm would have resisted, giving POP3 mail credentials.
Reading the mailbox surfaced a temporary SSH password an admin had issued to all staff, together with an email showing one employee hadn’t yet rotated it. That account still had the temporary password set, so SSH let me in as that user.
From the user shell, enumeration (LinPEAS) flagged an outdated kernel vulnerable to a local privilege-escalation exploit (CVE-2017-16995, CVSS 7.8). Compiling and running it returned root.
Fix: This is a chain of a public breach, weak password hashes, credentials passed around over unencrypted email, and an unpatched kernel. Force rotation after any breach, store secrets with modern salted hashing, don’t distribute passwords by plaintext email, and keep the kernel patched. The kernel patch alone would have stopped the final step even after everything upstream went wrong.
Host 5: Windows buffer overflow
The last host was the course’s buffer-overflow exercise, exploiting a vulnerable service to gain a shell through classic stack smashing rather than a configuration mistake. It’s the one box here that required actually writing an exploit.
Fix: Bounds checking, modern compiler mitigations (stack canaries, DEP/ASLR), and not running unmaintained network services.
What the whole exercise shows
Four of the five boxes fell with no exploit code at all. Default passwords, guest
shares, and credentials left in files did the work.
Patching matters, and two boxes did need it, but the cheaper wins were almost
always basic hygiene. Change default credentials, lock down share and sudo
access, keep secrets out of files and plaintext email, and segment the network so
one foothold isn’t a free pass to the next host. The most useful finding in most real
assessments is rarely the CVE. It’s the shortcut that shouldn’t have been there.