A network that could only be reached through the first host
I built this CMP110 project in 2021 to investigate network pivoting rather than treat it as a single tool or command. The lab placed an Ubuntu server at the edge of a virtual network and kept a Windows workstation and Active Directory domain controller behind a pfSense firewall. A Kali Linux machine sat on a separate external network.
The Windows systems could communicate inside their own subnet but could not connect directly to the Kali machine. Incoming traffic was directed towards the Ubuntu server, which represented a public-facing service that had already been compromised. The research question was straightforward: once an attacker controls that edge host, how much of the supposedly internal network becomes reachable, and how do different forwarding methods change that access?
The resulting report ran to 50 pages because most of the work was in the environment, routing, comparison, and troubleshooting. The project covered:
- a Windows Server 2012 R2 domain controller with DNS, Active Directory Domain Services, remote administration, and an SMB share
- a Windows 10 domain workstation
- an Ubuntu 18.04 server representing the exposed host
- a pfSense firewall joining isolated VMware networks
- a Kali Linux system representing the external testing position
- explicit firewall rules preventing the internal Windows systems from reaching the external network directly
All testing was conducted against this local environment.
The retired address plan made the trust boundaries explicit:
| System | Lab address and network | Role |
|---|---|---|
| Windows Server 2012 R2 | 192.168.2.128/24 |
Domain controller, DNS, SMB, RDP, and Windows remote management |
| Windows 10 workstation | 192.168.2.129/24 |
Domain client |
| Ubuntu 18.04 server | 192.168.2.2/24 |
Exposed SSH host and pivot |
| pfSense LAN | 192.168.2.254/24 |
Internal gateway |
| Kali test host | 203.22.0.134 on the external VMnet |
External assessment position |
The domain was named Nekrotic.com in the coursework. The credentials shown in the submitted build notes were disposable lab values and are not reproduced here.
Building the topology
The domain controller and workstation shared an isolated VMware network. I configured the domain, created a test user, joined the workstation, and used the domain controller as the workstation’s DNS server. Remote Desktop and Windows remote-management services provided internal services whose reachability could be tested through the edge host.
The domain controller also hosted an SMB share, giving the lab an internal file service as well as authentication and administration protocols. The workstation used the controller for DNS and authenticated with the domain test user, so the internal network behaved as a small Windows environment rather than a set of unrelated hosts.
The Ubuntu server was placed on the same protected side of pfSense but exposed through the firewall. SSH provided a stable way to model an established foothold without making the project depend on a separate initial-access exploit. On the other side, the Kali system could reach the exposed server but had no route to the internal Windows subnet.
pfSense had one interface on the internal VMnet and one on the external VMnet. The coursework deliberately created an unsafe edge policy: broad TCP forwarding directed external connections to Ubuntu, the Windows hosts were denied direct WAN access, and Ubuntu was permitted to initiate outbound connections. That combination made both forward listeners and reverse tunnels testable while preserving the central constraint that Kali could not route directly to the Windows subnet.
This topology separated two questions that are often blurred together:
- Can the external system reach the internal destination at the IP layer?
- Can a particular application carry its traffic through the compromised host?
A browser may only need an HTTP proxy. A scanner needs a method that supports many outbound connections. Remote administration clients need their own TCP flows. A routed tunnel changes the local routing table so that several tools can use the path without individual proxy support.
The firewall build also produced an early networking lesson. VMware reserved the first usable address on its virtual network for a host interface. Assigning the same address to pfSense caused competing ARP replies and intermittent loss of the default gateway after reboots. Moving the firewall away from that reserved address removed the collision. It was a configuration problem that initially looked like unreliable routing, and packet-level reasoning was what explained it.
The sequence was repeatable. After DHCP had initially populated a guest’s ARP cache with the firewall MAC, communication worked. Following a reboot, both the VMware host adapter and pfSense answered for the same gateway address; the VMware interface responded first and traffic intended for pfSense followed the wrong MAC. Moving the LAN gateway to .254 removed the duplicate ownership rather than masking the symptom with static ARP entries.
Establishing what the foothold could see
Before introducing forwarding tools, I used the information already available on the Ubuntu host to establish its network position: interface addresses, routes, neighbouring systems, and the default gateway. I then used a portable scanner in the lab to compare that local view with what the external Kali system could see.
The internal scan exposed the expected characteristics of a Windows domain environment. Ports associated with DNS (53), Kerberos (88 and 464), NetBIOS/SMB (139 and 445), LDAPS (636), Remote Desktop, and Windows remote management were visible from Ubuntu. The same services were not directly reachable from Kali.
The project also examined how legacy name-resolution traffic and authentication attempts can disclose domain context from inside a network. In the controlled LAN, a responder-style listener received challenge-response authentication material when a client attempted to resolve or access a name that did not exist. That result was used to demonstrate the risk of local name-resolution poisoning, not to publish captured values or a credential-recovery workflow.
The purpose was not simply to collect open ports. It was to identify which services required direct TCP reachability, which could be used through an application proxy, and which parts of the environment remained hidden until the external system gained a route through the Ubuntu host.
The experiment also demonstrated the difference between transferring a tool to the foothold and keeping tools on the assessment machine. A portable scanner had to be copied to Ubuntu and executed there. SOCKS and routed tunnelling let compatible tools remain on Kali while their connections originated through the established channel. That affects deployment effort, host artefacts, tool compatibility, and the telemetry available to defenders.
Comparing forwarding methods
Single-service port forwarding
Socat was used to study direct forwarding between one externally reachable port and one internal service. This was the simplest model: traffic arriving at the exposed host was relayed to a chosen destination behind the firewall.
It worked for demonstrating access to a specific TCP service and made the packet path easy to understand. Its limitation was equally clear. Each new destination or service needed another forwarding rule and another listening port. It also depended on inbound reachability through the firewall, so it became less useful as the ingress policy became stricter.
The listener also created an obvious network and host artefact: a new process bound to a port on the edge server and relayed connections to an internal management service. A defender could compare that listener, its parent process, and its internal destination against the server’s expected service baseline.
I also tested a reverse form intended to have the internal host initiate the connection back to the external side. That attempt timed out in the lab and was not presented as successful. Keeping the failed result in the report was useful because it separated the forwarding concept from the exact assumptions made by one implementation.
SOCKS proxying
Chisel was used in both forward and reverse proxy roles. In the reverse arrangement, the Ubuntu host initiated the connection to the external system and exposed a SOCKS interface on the Kali machine. Proxychains then directed compatible command-line tools through that interface, while FoxyProxy provided the equivalent path for browser traffic.
This method supported access to more than one internal host without defining a separate external port for every service. It also demonstrated the practical difference between a network route and an application-aware proxy. Tools that understood SOCKS, or could be wrapped by Proxychains, worked through the path. Others still expected direct network reachability.
Browser access to the pfSense management interface worked through FoxyProxy, while command-line clients used Proxychains. DNS resolution needed deliberate handling because resolving a private hostname on the external machine could fail or leak the query outside the tunnel even when the subsequent TCP connection was proxied.
The forward proxy variant placed the listener on the compromised host. It was workable in the deliberately permissive lab but depended on the firewall allowing the external side to reach that listener. Comparing the two variants showed why outbound policy is relevant to pivoting: a network that blocks unsolicited inbound traffic can still permit an internal process to establish a long-lived outbound tunnel.
Routed access with sshuttle
Sshuttle produced the most transparent user experience in this environment. It used the existing SSH access to create a VPN-like path and inserted routes for the protected subnet on the Kali system. Applications could then address internal systems normally instead of being configured one by one for a SOCKS proxy.
That made it suitable for comparing scanners, browser access, and remote administration over the same path. It also depended on valid SSH access and a compatible host, so it was not a universal replacement for the other techniques.
Unlike a full layer-two VPN, the lab use of sshuttle did not make Kali a native participant in every local broadcast protocol. It provided routed handling for the selected subnet and made ordinary TCP-oriented tools easier to use. That was sufficient for reaching RDP and other internal services, but it did not erase protocol limitations.
The comparison was therefore about operational properties rather than declaring one winner:
| Approach | Lab use | Main constraint |
|---|---|---|
| Direct port forward | Reach one known TCP service | One mapping per destination and service |
| SOCKS proxy | Carry several compatible applications | Application or wrapper must support proxying |
| Reverse SOCKS | Work with restrictive inbound policy | Requires an outbound control connection |
| Routed SSH tunnel | Give multiple tools subnet-like access | Depends on SSH access and routing support |
When the path worked but the application did not
One Windows remote-management test failed when using a hash-based authentication option even though the forwarded service was reachable. I used the known lab password to verify that the network path itself worked.
That distinction prevented an authentication failure from being misdiagnosed as a tunnelling failure. It also established a troubleshooting sequence I reused in later network work:
- verify the destination service locally
- verify the compromised host can reach it
- verify the forwarding channel is established
- verify packets arrive at the expected end of the tunnel
- only then debug the application protocol or authentication method
This split also applied to names and routes. A service could be listening and the tunnel established while the client still used the wrong destination, resolved a name externally, selected an unsupported authentication method, or expected UDP behaviour from a TCP-focused proxy.
Segmentation and monitoring conclusions
The lab showed that a firewall boundary loses much of its value when an exposed host has broad access to internal systems. The Ubuntu server did not need to contain sensitive data itself; its network position was enough to make it a route towards identity and administration services.
The report proposed several defensive changes:
- place public-facing services in a DMZ with narrowly defined internal destinations
- restrict outbound traffic from edge servers rather than concentrating only on inbound rules
- avoid exposing management services across trust boundaries
- monitor unusual long-lived outbound connections and proxy-like traffic
- baseline process and network behaviour on internet-facing systems
- use host and network telemetry together, since encrypted tunnels reduce the value of payload inspection alone
- disable legacy name-resolution behaviour where it is not required
- minimise credential exposure and privileged remote administration paths
The report also considered deeper packet inspection, DNS sinkholing, and host- and network-based intrusion detection. I would apply those with clearer expectations now. Inspection may identify known tools or protocol anomalies, but encryption, protocol imitation, privacy requirements, and false positives limit content-based detection. Egress allow-listing and workload identity can prevent many unnecessary paths before inspection is needed.
Useful telemetry for this particular lab would include:
- an internet-facing SSH process creating connections to domain-controller management ports
- new listeners on the edge host
- long-lived outbound connections from a server that normally only answers requests
- one edge process connecting to many internal hosts or ports
- unexpected SOCKS-like traffic and DNS behaviour
- Remote Desktop or WinRM access sourced from the edge segment
- legacy name-resolution requests followed by authentication attempts
- imported executables or changes to executable permissions under temporary paths
Network data describes the connection; process telemetry identifies which executable created it. Together they provide a stronger pivoting signal than either source alone.
The main result was a working comparison of forwarding models in a network I had built specifically to make routing and trust boundaries visible. It was also an early link between offensive access and defensive architecture: once a system becomes a foothold, its allowed connections define the next part of the attack surface.
The proposed next phase was to repeat the tests behind a more restrictive enterprise firewall, compare which channels were blocked or inspected, test Windows-based pivots rather than only Linux, and evaluate network and host detections against each method. That work was identified in the report but not completed as part of this project.
This is historical coursework. The product versions and individual tools reflect the 2021 lab, but the underlying questions about segmentation, egress control, management-plane exposure, and tunnel detection remain relevant.