What is Netcat?

Netcat (nc) is a command-line tool for making TCP or UDP connections. It can help test whether a service is reachable, send or receive simple data, and troubleshoot network paths. The available options vary between Netcat implementations, so check the manual for the version installed on your system.

Netcat can also be misused to create command shells over network connections. This guide explains that risk at a high level and focuses on safe diagnostics and defensive measures.

Reverse shells at a glance

In a reverse shell, a machine initiates an outbound connection to another system and exposes a command interface over that connection. Because many networks allow some outbound traffic, defenders should monitor outbound connections as well as inbound access.

The same technique can appear in authorized security testing and in attacks. Authorization, scope, and safeguards determine whether a test is appropriate.

OpenBSD Netcat

OpenBSD Netcat is one implementation of nc. Its options differ from other versions, and it does not provide the -e option found in some legacy variants. Don’t assume that a command or option supported by one Netcat build works on another.

On Debian or Ubuntu, check which package provides nc and read its local manual:

$ nc -h
$ man nc

Safe connectivity checks

Check whether a TCP service is reachable

$ nc -vz -w 3 example.com 443

This attempts a TCP connection to port 443, reports whether it succeeded, and times out after three seconds. Use a host and port you are authorized to test.

Exchange harmless text between two machines

On a machine you control, start a temporary listener:

$ nc -l 4567

From another machine you control, connect and send a test message:

$ printf 'connectivity test\n' | nc -N server.example 4567

Replace server.example with the listener’s address. Stop the listener when you finish. The example sends text only; it does not start a shell.

A listener may be reachable only if the host firewall and network allow the connection. Avoid opening a port to the public internet for a test. If testing across machines, use a private lab network or an approved environment.

Defensive guidance

Restrict outbound traffic

Use host and network firewalls to allow only the outbound connections your systems need. Apply rules by host, application, destination, and port where practical, and review them as services change.

Monitor network activity

Investigate unexpected outbound connections, especially from shell processes, scripting tools, or servers that do not normally initiate connections. Useful data sources include firewall logs, endpoint telemetry, and network monitoring tools such as Zeek or Suricata.

For a quick local view on Linux:

ss -tunap

This lists TCP and UDP sockets and, when permissions allow, the associated processes. Treat it as a snapshot, not a complete monitoring solution.

Use least privilege

Give users and services only the permissions they need. In sudo, allow specific administrative commands rather than granting broad access and trying to subtract dangerous commands afterward. Sudoers command exclusions are not a reliable way to prevent shell access when a user can run other programs or has unrestricted privileges.

Apply mandatory access controls carefully

AppArmor or SELinux policies can limit what a process may do, including network access. Policies need to match the system’s needs and should be tested before enforcement; a broad rule can disrupt legitimate applications. Use distribution documentation and a qualified administrator when writing or changing system-wide profiles.

Don’t rely on BASH_CMDS to disable networking

Unsetting BASH_CMDS does not disable Bash’s /dev/tcp feature. That feature is part of Bash’s redirection behavior. Use firewall policy, process restrictions, and monitoring to control network access instead.

If you suspect a reverse shell

• Isolate the affected host from the network if your incident-response plan calls for it.
• Preserve relevant endpoint, firewall, and authentication logs.
• Identify the process and account associated with the connection.
• Follow your organization’s incident-response process before terminating processes or rebooting, since those actions can remove useful evidence.

Netcat is a useful diagnostic tool, but its flexible networking features can also be abused. Keep testing within systems you own or are explicitly authorized to assess, and focus defenses on controlling and monitoring network activity.

Thanks for reading SNUBmonkey.