A White Hat's Penetration Test

From DNS Enumeration to Network Mapping

It was just past 1:20 a.m. I pulled up a fresh cup of coffee and launched the command line on my Gentoo box. The client had handed over a single piece of information: the domain name, company.com. That was all I needed to start a remote penetration test, following the rules of engagement and with full authorization in place. I began with a basic DNS enumeration to gauge the size and structure of the target network.

Using nslookup – still available even though it’s been deprecated in favor of dig – I queried for name server records. The output confirmed that the domain’s authoritative DNS was handled by the ISP, with two nameserver entries pointing to dns.isp.net and dns2.isp.net. The IP addresses 193.117.205.95 and 193.117.205.94 were also visible, but the more important detail was that there was no zone transfer available; the domain was likely locked down from internal data leakage.

Next, I requested the MX records to identify the mail servers in use. The response revealed two mail exchangers: one hosted by the ISP and the other on a subdomain of the company itself, mail.company.com. The zero‑weight record hinted that the company maintained an on‑premises mail server, a potential entry point for further reconnaissance.

At 1:30 a.m., I ran a SYN scan against mail.company.com with nmap. The scan quickly surfaced several open TCP ports – telnet, SMTP, finger, HTTP, POP3, and IMAP – and the presence of a telnet service raised an eyebrow. The banner from the telnet service matched that of a Cisco router, suggesting that the host was acting as a gateway rather than a conventional mail server. I confirmed this by connecting to port 23 with nc and noting the “User Access Verification” prompt that followed the Cisco fingerprint.

While the telnet session did not provide direct credentials, it gave me a clue: the router likely exposed SNMP services. I launched a UDP scan targeting ports 161 and 162. The results confirmed that SNMP was enabled on port 161, while port 162 remained closed. I then used snmpenum.pl from the well‑known SNMP enumeration toolkit, assuming the community string was the default “public.” The script returned the router’s OS details – Cisco IOS 12.0(5)T – and confirmed the presence of a standard SNMP community configuration. This was promising because the read community string was intact while the write community string had been changed, a common misconfiguration that opens a path to further exploitation.

To retrieve the write community string, I ran a dictionary attack with the SolarWinds SNMP dictionary tool. After a brief but intensive cycle of requests, the tool reported success: the community string was discovered. With this in hand, I used the SNMP set operation to request a file transfer of the router’s configuration via TFTP. The router dutifully sent the configuration file to my machine, giving me a raw text dump that included the line “enable password 7 …” and the login password for the virtual terminal lines.

Running the Cisco Type 7 decryption routine on the password hash yielded the clear text: therouter. The same password was used for both the enable prompt and the console login, a glaring weakness. I also noted that the configuration file defined static NAT mappings that forwarded TCP ports 143, 80, 110, and 25 from the public interface to an internal host with the address . This internal host was the company’s mail and web server, and the NAT rules effectively made it reachable from the outside world on the standard mail and web ports.

At this point I had a working map of the network perimeter: a Cisco router exposing SNMP, a compromised read‑write community string, a known administrator password for the router, and clear evidence of port forwarding to an internal Windows 2000 machine. The next step would be to broaden the attack surface inside the network and gain higher privileges on the internal server.

Compromising the Internal Infrastructure and Consolidating Control

With the internal IP address and the known port forwarding in place, I focused on the internal Windows 2000 server. A quick nc probe on port 80 returned an HTTP/1.1 400 response that identified the web server as Microsoft‑IIS 5.0, while port 110 returned a POP3 banner confirming the presence of Microsoft Exchange 2000. These details confirmed the server’s operating system and exposed an opportunity to exploit known unpatched vulnerabilities that were still active on that platform.

The client’s network had not patched for the notorious RPC‑DCOM vulnerability, so I opted to use an exploit that targets that vector. However, the exploit needed to be directed to the internal server, not the public router. I re‑configured the router’s NAT table to add additional static translations for ports 139, 135, 445, and 3389 – the SMB, RPC, and Remote Desktop services. I also opened an extra port, 10000, to serve as a conduit for a reverse shell. Each new rule used the “extendable” keyword so that I could later remove them cleanly if needed.

Launching the RPC‑DCOM exploit against the router caused the payload to be sent to the internal server thanks to the newly created NAT rules. The exploit succeeded and returned SYSTEM level privileges on the Windows 2000 host. At the command prompt I dropped pwdump4.exe, a well‑known tool for dumping SAM hashes. Running the tool against the local machine produced a text file with raw NTLM hashes. Using TFTP, I retrieved that file back to my attacker machine.

Hash cracking is often the bottleneck in a penetration test, but I had recently built an extensive set of rainbow tables using the RainbowCrack tool. Running rcrack.exe against the hash file yielded clear text passwords in under ten minutes, a dramatic improvement over traditional brute‑force tools. The output listed several accounts, the most critical being the Administrator account, with a password of Administrator. With that credential, I opened an RDP session to port 3389 on the internal server, greeted by a Windows log‑on prompt. The Administrator password let me log in, and I was now fully compromised on the internal network.

To ensure I could maintain persistence without leaving obvious traces, I copied a modified version of the KaHT II RPC‑DCOM autohacker onto the server. The script was configured to trigger on each successful exploitation and automatically tftp the latest SAM file to my machine, keeping me in the loop without manual intervention. With the internal system fully controlled, I paused the attack as the engagement’s objectives had been achieved.

Throughout this exercise I relied heavily on publicly available tools and standard OSI layer concepts. The workflow – start with DNS, surface scan, identify misconfigurations, pivot via NAT, exploit a known vulnerability, extract credentials, and finally secure persistence – is a pattern that many professional penetration testers employ. This case study demonstrates that even a single piece of information, like a domain name, can lead to a comprehensive assessment of a corporate network’s defenses when combined with the right methodology and tools.