Long before I ever touched a proper vulnerability scanner, I was using netcat to figure out why a service on a remote box wasn’t responding. It’s one of those tools that looks trivial on the surface — send and receive data over a socket — and turns out to be endlessly useful precisely because it does that one thing so well. This article covers netcat from the basics through to real diagnostic and security workflows.
What Is Netcat?
Netcat (nc) is a general-purpose networking utility for reading and writing data across TCP and UDP connections. It was originally written by Hobbit in 1995. Today, the two variants you’ll actually run into are GNU Netcat and OpenBSD Netcat (the latter is what ships by default on Debian/Ubuntu/Kali as netcat-openbsd). There’s also Ncat, bundled with Nmap, which adds SSL/TLS support and a few modern conveniences.
At its core, netcat treats a network connection like a Unix pipe — you can pipe data into it, out of it, or chain it with other command-line tools, which is exactly what makes it so flexible.
How Netcat Works Internally
- Socket abstraction: Netcat opens a raw TCP or UDP socket and connects standard input/output to it. Whatever you type (or pipe in) gets sent across the wire; whatever comes back gets printed to your terminal.
- Client and listener modes: In client mode, netcat initiates a connection to a remote host/port. In listener mode (
-l), it binds to a local port and waits for an incoming connection — functionally a minimal server. - Protocol agnosticism: Netcat doesn’t know or care what protocol is riding on top of TCP/UDP. It just moves bytes. That’s why it can talk raw HTTP, SMTP, or a custom protocol equally well — you’re just typing the protocol commands yourself.
- Redirection-friendly design: Because it uses stdin/stdout, netcat composes naturally with shell redirection,
|pipes, andtee, which is the basis of most of its more advanced use cases (file transfer, relaying, banner grabbing).
Installation
# Debian/Ubuntu/Kali (OpenBSD variant, the modern default)
sudo apt install netcat-openbsd -y
# GNU variant (has a couple of extra options like -c)
sudo apt install netcat-traditional -y
# Ncat (bundled with Nmap, has TLS support)
sudo apt install nmap -y # ncat comes along with it
Verify:
$ nc -h
OpenBSD netcat (Debian patchlevel 1.226-1ubuntu2)
usage: nc [-46CDdFhklNnrStUuvZz] [-I length] [-i interval] [-M ttl]
[-m minttl] [-O length] [-P proxy_username] [-p source_port]
[-q seconds] [-s sourceaddr] [-T keyword] [-V rtable] [-W recvlimit]
[-w timeout] [-X proxy_protocol] [-x proxy_address[:port]]
[destination] [port]
Basic Syntax
nc [options] host port
nc -l [options] port # listen mode
Core Usage Examples
Simple connection (like a manual HTTP request)
nc example.com 80
GE T / HTTP/1.1
Host: example.com
(Type the request lines manually and press Enter twice.)
Port scanning with netcat
$ nc -zv 127.0.0.1 20-25
nc: connect to 127.0.0.1 port 20 (tcp) failed: Connection refused
nc: connect to 127.0.0.1 port 21 (tcp) failed: Connection refused
nc: connect to 127.0.0.1 port 22 (tcp) failed: Connection refused
nc: connect to 127.0.0.1 port 23 (tcp) failed: Connection refused
nc: connect to 127.0.0.1 port 24 (tcp) failed: Connection refused
nc: connect to 127.0.0.1 port 25 (tcp) failed: Connection refused
-z means “zero-I/O mode” (just check if the port is open, don’t send data), -v is verbose. On a host with something actually listening, you’d see succeeded! instead of failed.
Setting up a listener and connecting to it
Terminal 1 (listener):
nc -l 4444
Terminal 2 (client):
echo "hello" | nc -w1 127.0.0.1 4444
Verified output on the listener side:
hello
This is the foundation of everything from simple chat tools to reverse shell listeners in authorized red-team exercises.
File transfer
Receiver:
nc -l 4444 > received_file.txt
Sender:
nc -w2 192.168.1.10 4444 < file_to_send.txt
Banner grabbing
nc -nv 192.168.1.10 22
Connecting to an SSH port and reading the immediate banner is one of the oldest tricks for service identification when a full Nmap scan isn’t available.
Chat-style two-way connection
# Host A
nc -l 4444
# Host B
nc 192.168.1.10 4444
Anything typed on either side appears on the other — a genuinely useful trick for quick, un-authenticated communication during lab exercises or CTF challenges.
UDP mode
nc -u 192.168.1.10 53
Useful for testing UDP-based services like DNS or SNMP manually.
Real-World Use Cases (Authorized Lab Environments Only)
1. Service and banner verification during a pentest. When Nmap’s version detection is inconclusive, connecting directly with netcat and reading the raw banner often clarifies exactly what’s running.
2. Reverse and bind shell handling in authorized red-team exercises. In a lab environment with explicit authorization, a listener (nc -lvp 4444) can catch an incoming reverse shell connection from a target during a controlled exploitation exercise — this is standard practice in OSCP-style labs and CTFs, never against systems without permission.
3. Firewall and ACL testing. Setting up a listener on one side of a segmented network and attempting a connection from the other side is a quick, low-noise way to verify that a firewall rule actually blocks (or allows) traffic as intended.
4. Incident response and forensics. Investigators sometimes use netcat to transfer memory dumps or log files off a compromised (but still reachable) host to an isolated analysis machine without needing SSH or SCP configured.
5. Testing custom application protocols. When developing or auditing a custom TCP service, netcat lets you manually send raw payloads and inspect exact responses — something a browser or standard client abstracts away.
Workflow and Automation
Netcat pairs naturally with shell scripting:
#!/bin/bash
# quick port checker for a list of hosts
for host in $(cat hosts.txt); do
nc -zv -w1 "$host" 22 2>&1 | grep succeeded
done
# relay traffic between two hosts (simple proxy)
mkfifo /tmp/pipe
nc -l 8080 < /tmp/pipe | nc destination_host 80 > /tmp/pipe
Integration with Other Tools
- Nmap: use
ncto manually confirm any ambiguous result fromnmap -sV. - Metasploit:
multi/handleris often used instead of netcat for catching more complex payloads, but netcat remains the go-to for simple, dependency-free shells during lab exercises. - tcpdump/Wireshark: pair a netcat session with a packet capture running alongside it to see exactly what’s on the wire — an excellent way to learn protocol internals.
Performance and Troubleshooting
| Symptom | Likely Cause | Fix |
|---|---|---|
| “Connection refused” | Nothing listening on that port | Confirm the service is actually running/bound |
| Connection hangs indefinitely | No -w timeout set | Add -w <seconds> to bound wait time |
| Listener doesn’t accept second connection | Default nc closes after one client | Use -k (OpenBSD variant) to keep listening |
| UDP “connection” always appears to succeed | UDP is connectionless — netcat can’t confirm delivery the way TCP does | Cross-check with an application-level response or a dedicated UDP scanner |
Best Practices and Common Mistakes
- Never leave a netcat listener open on a production or internet-facing host — it has no authentication and anyone who finds it can connect.
- Use Ncat instead of classic netcat when you need TLS — plain netcat sends everything, including anything sensitive, in cleartext.
- Always set
-wtimeouts in scripts, or a hung connection will stall your automation indefinitely. - Don’t assume netcat variants behave identically — GNU netcat and OpenBSD netcat have slightly different flags (
-efor command execution exists in some variants and not others, largely for security reasons). - Only use it for shells/relays in environments you’re authorized to test. Setting up unauthorized listeners on systems you don’t own is exactly the kind of activity that gets flagged as malicious network activity.
Practical Lab Example
# Lab: two VMs on an isolated virtual network, 10.0.0.5 (server) and 10.0.0.10 (client)
# On the server VM — start a listener
nc -l 4444
# On the client VM — connect and send a test message
echo "connectivity test from client" | nc -w2 10.0.0.5 4444
# Expected output on server VM:
# connectivity test from client
FAQ
Is netcat illegal to use? No. It’s a completely legitimate, widely used diagnostic tool. Using it to connect to or listen on systems without authorization is what would cross a legal line, same as with any networking tool.
What’s the difference between netcat and Ncat? Ncat (bundled with Nmap) adds TLS/SSL encryption, better IPv6 support, and a broker mode for connecting multiple clients — netcat is the older, simpler tool without built-in encryption.
Can netcat replace a full port scanner like Nmap? For a handful of ports, yes, in a pinch (-zv with a port range). For comprehensive scanning with service/version detection and OS fingerprinting, Nmap is the right tool.
Why do some netcat guides mention -e for spawning a shell and others don’t? Many modern packages (including OpenBSD netcat) compile out the -e option specifically because of its history of misuse in unauthorized shell access — it’s a deliberate security decision by packagers.
Is netcat traffic encrypted? No, plain netcat sends data in cleartext. Use Ncat with --ssl, or tunnel through SSH/stunnel, if you need confidentiality.
Summary
Netcat earns its “Swiss Army knife” reputation by doing one thing — moving bytes over a socket — with almost no assumptions layered on top. That simplicity is exactly why it’s stayed relevant for three decades: it’s the tool you reach for when you need to see exactly what’s happening on the wire, without a GUI, without a heavyweight client, and without guessing.
References
- OpenBSD netcat man page:
man nc - Ncat official documentation: https://nmap.org/ncat/
- Nmap project GitHub (includes Ncat source): https://github.com/nmap/nmap
