The Mindset
When you land on a box, the network answers three questions:
- Where am I? — Subnets, interfaces, routing — what segment of the network is this machine on?
- What can I reach? — Other hosts, internal services, domain controllers, databases
- How do I move? — Pivot routes, port forwards, dual-homed machines
A machine with two network interfaces is almost always a pivot point into a separate network segment.
Network Interfaces
# Show all interfaces and IP addresses
ip addr
ip a # shorthand
# Show routing table
ip route
ip r
# Show ARP table (other hosts on the same subnet)
ip neigh
# Bring an interface up or down
sudo ip link set eth0 up
sudo ip link set eth0 down
ifconfig
# eth0: flags=4163<UP,BROADCAST,RUNNING,MULTICAST>
# inet 10.10.10.5 netmask 255.255.255.0 broadcast 10.10.10.255
# inet6 fe80::...
# ether 00:50:56:b9:...
| Field | Pentest Relevance |
|---|
inet | IPv4 address and subnet |
inet6 | IPv6 — often forgotten, sometimes accessible |
| Multiple interfaces | Machine may bridge two networks — pivot opportunity |
Spot a Dual-Homed Machine
ip addr | grep "inet " | grep -v "127.0.0.1"
# If you see two non-loopback IPs on different subnets:
# inet 10.10.10.5/24 ← network 1 (your entry point)
# inet 172.16.0.5/24 ← network 2 (new territory to explore)
Routing
# View routing table
ip route
route -n # legacy
# Example output:
# default via 10.10.10.1 dev eth0
# 10.10.10.0/24 dev eth0 proto kernel
# 172.16.0.0/24 dev eth1 proto kernel ← second network reachable
# Add a static route (for pivoting)
sudo ip route add 172.16.0.0/24 via 10.10.10.1
Active Connections & Open Ports
ss — Socket Statistics (Modern)
# All listening ports
ss -tuln
# All connections with process names (needs root for full output)
ss -tulnp
# Established connections only
ss -tn state established
# Filter by port
ss -tuln | grep :3306 # MySQL
ss -tuln | grep :5432 # PostgreSQL
ss -tuln | grep :6379 # Redis
ss -tuln | grep :27017 # MongoDB
netstat — Legacy But Universal
# All listening ports
netstat -tuln
# With process names
netstat -tulnp
# All established connections
netstat -tn
# Routing table
netstat -rn
Services bound to 127.0.0.1 are invisible from outside but fully accessible
once you’re on the box. Always check for internal-only listeners — they’re
often the least hardened services on the system.
DNS & Host Resolution
# View DNS servers
cat /etc/resolv.conf
# View local host entries (may reveal internal hostnames)
cat /etc/hosts
# Resolve a hostname
nslookup internal-app.corp.local
dig internal-app.corp.local
# Reverse DNS lookup (IP → hostname)
dig -x 10.10.10.5
ping — Host Reachability
# Basic connectivity test
ping -c 4 8.8.8.8
traceroute — Path to a Host
traceroute 10.10.10.1
# Each hop = a router or gateway between you and the target
# Asterisks (*) = host not responding to ICMP — still exists
Internal Network Discovery
Once you have a foothold, map what else is reachable:
# ARP table — hosts that recently communicated with this machine
ip neigh
arp -a
# Quick ping sweep of the local subnet
for i in $(seq 1 254); do
(ping -c 1 -W 1 10.10.10.$i > /dev/null 2>&1 && echo "10.10.10.$i is up") &
done; wait
# Port scan from the compromised host (if nmap is available)
nmap -sn 10.10.10.0/24
# If you have SSH access to the victim, scan the hidden network from your Kali instead
# Step 1 — open a SOCKS proxy through the victim (run on your Kali)
ssh -D 1080 user@10.10.10.1
# Step 2 — scan through the tunnel (run on your Kali in a new terminal)
# -sT = TCP connect scan, required because proxychains can't forward raw packets
proxychains nmap -sT 172.16.0.0/24
# TCP connect scan without nmap (bash)
for port in 22 80 443 445 3306 5432 8080; do
(echo >/dev/tcp/10.10.10.10/$port) 2>/dev/null && echo "Port $port open"
done
Accessing Internal Services via Port Forwarding
When you find a service listening on localhost of the target, forward it to your machine:
# Local port forward — access target's port 8080 on your localhost:9090
ssh -L 9090:127.0.0.1:8080 user@target
# Forward a port on an internal host through the pivot
ssh -L 9090:172.16.0.10:80 user@pivot
# Dynamic SOCKS proxy — route all traffic through the pivot
ssh -D 1080 user@pivot
# Then use proxychains: proxychains nmap -sT 172.16.0.0/24
Network Access Control
Understanding what’s in place helps you work around it or identify weaknesses:
| Mechanism | What It Does | Where to Look |
|---|
| Firewall (iptables/nftables) | Filters traffic by port/IP | iptables -L -n |
| TCP Wrappers | Controls service access by IP | /etc/hosts.allow, /etc/hosts.deny |
| SELinux / AppArmor | Process-level access control | sestatus, aa-status |
# View firewall rules
sudo iptables -L -n -v
sudo nft list ruleset
# TCP Wrappers config
cat /etc/hosts.allow
cat /etc/hosts.deny
# SELinux status
sestatus 2>/dev/null
# AppArmor status
aa-status 2>/dev/null
Configuring Interfaces (When Needed)
Occasionally you’ll need to configure a network interface — when setting up a pivot or a test environment:
# Assign a static IP
sudo ip addr add 192.168.1.2/24 dev eth0
# Set default gateway
sudo ip route add default via 192.168.1.1
# Edit persistent config (Debian/Ubuntu)
sudo vim /etc/network/interfaces
# auto eth0
# iface eth0 inet static
# address 192.168.1.2
# netmask 255.255.255.0
# gateway 192.168.1.1
# dns-nameservers 8.8.8.8
# Restart networking
sudo systemctl restart networking
