Penetration Test : My Meanest Hack

From Permission to Plan: Setting the Stage

When a large organization invites a professional to perform a proof‑of‑concept hack, the rules of engagement usually feel like a tight knot of constraints. You get a scope document, a list of allowed techniques, and a strict deadline. But this time, the client gave me a different mandate: “I want you to act like a hacker who stops at nothing to get an interactive session on an internal machine protected by two firewalls and an IDS.” That was the first hint that this test would differ from a typical penetration exercise. In a normal engagement, we would avoid social engineering, stick to publicly documented exploits, and stay in the sandbox. Here, we had the freedom to do whatever was needed, which turned out to be a blessing and a challenge in equal measure.

The target machine lay inside a corporate network that was segmented by an external firewall, a DMZ, and a second internal firewall. The only entry point from the outside world was the DMZ, and every outbound connection was tightly controlled by the IDS and the internal firewall. A quick reconnaissance revealed that the machine did not have an open SSH port, no open RDP, and no obvious service exposed to the Internet. The same machine also had no public-facing web services or exposed APIs that could be used to piggy‑back a payload. That meant the only viable path to get inside was to make the machine reach out to us. In other words, we had to turn the target inside out and create a reverse connection.

In the early hours of the morning, I called the organization’s phone line. I was polite, I posed as a potential customer, and I asked to speak to the secretary who managed the account for the target computer. The secretary, following standard corporate procedure, introduced herself and gave me her email address after confirming that I was authorized to reach out about a product. That conversation seemed ordinary, but it was the starting point of a carefully orchestrated social‑engineering chain.

I then crafted an HTML e‑mail with a tiny netcat payload that would establish a reverse shell when the user opened the message. The idea was simple: the victim would open the attachment, the embedded script would execute, and a listener on my side would receive a shell. A few minutes later, the secretary opened the e‑mail out of curiosity, and the reverse shell appeared in my terminal. I could see the prompt, the machine name, and the current user – a sign that the foothold was successful.

After establishing the first connection, I knew I had to guard against a common pitfall: the remote machine could be shut down, the network could block the outbound channel, or the victim could simply close the e‑mail client. To avoid losing the only connection, I used the at command on the target to schedule a netcat shell every 15 minutes. Every quarter of an hour, the target re‑initiated the reverse connection automatically, keeping me in touch even if the first session dropped. This routine became the safety net that allowed me to move to the next stage without fear of losing access.

With a persistent channel in place, I turned my attention to building a proper toolkit on the compromised machine. The internal network’s firewall rejected TFTP traffic, so I couldn’t rely on the usual file transfer method. Instead, I exploited a minor feature of the internal FTP client: I could echo FTP commands into a text file and let the client execute them line by line. Using this trick, I downloaded a small collection of files that included VNC binaries and a custom registry file. The registry file was pre‑configured with a VNC password and a flag that allowed local connections. This set of tools would allow me to pivot from a simple shell to a fully interactive GUI session once I found a way around the outbound restrictions.

That first phase had a clear narrative: social engineering to get a reverse shell, persistence through scheduled shells, and a stealthy method to bring a small toolkit onto the target. All the while, I kept my actions within the parameters of the engagement: I had no direct external access, I wasn’t scanning or exploiting other hosts, and every step was documented for the final report. The next challenge was to expose the internal machine to my VNC client without touching the two firewalls that guarded the network.

Maintaining the Connection: Backup Shells and Tool Transfer

After the initial foothold, my objective was to expand the capabilities of the compromised system. A plain shell is powerful, but it limits the scope of what I can do. To truly simulate a hacker’s mindset, I needed a graphical interface that would let me interact with the Windows desktop as if I were sitting in front of it. The usual path would involve installing a VNC server and then connecting through it, but the internal network’s outbound restrictions made that path impossible without an intermediary.

Because the internal firewall blocked TFTP, I had to resort to a less obvious method for transferring files. The internal FTP client on the target allowed me to send a script of commands to a text file, which the client could then parse and execute. I created a script that instructed the client to download a package of utilities: a lightweight VNC server, a VNC client binary for the target, and a custom registry file that would configure the VNC server to accept local connections and set a predictable password. This registry tweak was crucial; without it, the VNC server would prompt for a password every time, stalling my process. By pre‑configuring the registry, I ensured a smooth installation once the files were in place.

The next step involved installing the VNC server. I followed a set of commands I had found on a public resource that detailed the installation of an open‑source VNC server on Windows. The commands were straightforward: unzip the package, copy the binaries to the system32 directory, and set the service to start automatically. Despite the tight outbound policies, the local execution of the installation script succeeded because all the necessary files were already on the machine.

At this point, the VNC server was installed, but it remained blocked by the two firewalls. Port 5900, the default VNC port, was not reachable from my network. I could not simply open a port on the internal firewall, and the IDS was actively logging attempts to open outbound connections on that port. To bypass this, I decided to create a reverse tunnel that would forward the internal VNC port to a port on my machine. This approach would give me a local endpoint to connect to, without exposing any new ports on the target network.

Implementing this required a few tools. On my side, I used plink.exe, the command‑line version of PuTTY, which is capable of creating SSH tunnels on Windows. On the target machine, I installed the OpenSSH server that ships with Cygwin. This combination allowed me to establish an SSH session from the target to my attacker machine and forward traffic from the internal VNC port to a local port on my laptop.

The tunnel was set up by instructing plink to listen on the target’s local machine for connections on port 5900 and forward them to a specified port on my machine. Once the tunnel was established, I verified the mapping by running netstat -a on my laptop. The command revealed that port 5900 was now listening and linked to the target’s machine, confirming that the tunnel was active.

With the tunnel in place, I launched my local VNC client and pointed it to localhost:5900. The client displayed a password prompt that matched the value I had inserted into the registry file. After entering the password, I was connected to the target’s desktop. The session was surprisingly responsive, thanks to the SSH tunnel’s compression. I could now see the full desktop, interact with applications, and even manipulate the registry to make further changes to the system.

Throughout this process, I kept a log of every command executed, every file transferred, and every configuration change. This documentation would later become part of the engagement report, allowing the client to understand exactly how the compromise was achieved and what controls could be tightened to prevent a similar attack in the future.

Breaking Through the Outbound Barrier: SSH Tunneling to VNC

Once the VNC server was installed and the registry tweaks were applied, the only remaining obstacle was the internal firewall’s prohibition on outbound traffic to port 5900. Directly opening a VNC connection from my laptop to the target machine was impossible. Instead, I used SSH tunneling to create a secure, encrypted bridge between the internal network and my workstation. This approach is commonly used in penetration testing to bypass network restrictions, but it is rarely executed on Windows machines.

The SSH client I selected was plink.exe, a command‑line tool that ships with the PuTTY suite. Plink can create SSH tunnels, forward ports, and execute commands over an SSH session, all from the Windows command prompt. On the target side, I installed the OpenSSH server bundled with Cygwin. This setup provided the necessary components to initiate an SSH connection from the compromised machine back to my attacker machine.

To establish the tunnel, I opened a command prompt on my laptop and ran:

This command instructed Plink to connect to the SSH server on the target machine using the supplied credentials, and to forward the local port 5900 on the target to port 5900 on my laptop. Because the target machine was already running a VNC server listening on 5900, the tunnel essentially mirrored the VNC traffic across the SSH connection.

After the tunnel was active, I verified its status by running netstat -a on my laptop. The output showed that port 5900 was listening, and the connection was linked to the target machine’s IP address. This confirmed that any traffic sent to localhost:5900 on my laptop would be securely forwarded to the VNC server on the target.

With the tunnel in place, I launched my VNC client and pointed it to localhost:5900. The client presented a password prompt, which I answered with the password set in the registry. The connection succeeded, and I was greeted with the target’s desktop. The responsiveness of the session was higher than I expected; the SSH tunnel’s compression settings helped keep latency low, and the fact that both ends were on Windows eliminated some of the overhead that often plagues remote desktop sessions.

The entire process demonstrated a powerful technique: turning an internal machine into a remote host without exposing new ports on the network. By combining a reverse SSH tunnel with a pre‑configured VNC server, I was able to maintain a full GUI session while staying within the constraints of the organization’s firewall policies.

Once the session was established, I explored the desktop, opened command prompts, and verified that the VNC session worked for file transfers and remote execution. While I could have launched more elaborate attacks at that point, the scope of this engagement was limited to demonstrating the feasibility of an interactive session. The night was late, and the client’s deadline was approaching, so I wrapped up the session, closed the SSH tunnel, and logged off the target machine. The engagement had met its objective: a fully functional, GUI‑based remote session achieved through a combination of social engineering, persistence, stealthy file transfer, and port tunneling on Windows.