Rether / docs
security/reconnaissance/Reconnaissance - SH
reference

Reconnaissance - SH

updated 2026.09.03created 2026.07.06~4 min

Once you have an IP and nothing else, reconnaissance is what turns it into a target: is the host reachable, what operating system is behind it, and which services is it exposing? This is the first step of a black-box engagement — see Pentest SH for where it fits.

Bash variables

Every command below reads the target from two variables, so a box can be swapped by editing a single line. Fill them in before anything else — an empty assignment is valid shell and silently breaks every command that follows.

// shell
#TARGET_NAME=jerry TARGET_IP=10.129.43.3

Ping

Start with a ping to see whether the host answers at all.

// shell
#ping -c 3 $TARGET_IP
PING 10.129.43.3 (10.129.43.3) 56(84) bytes of data. 64 bytes from 10.129.43.3: icmp_seq=1 ttl=62 time=23.7 ms 64 bytes from 10.129.43.3: icmp_seq=2 ttl=62 time=27.8 ms 64 bytes from 10.129.43.3: icmp_seq=3 ttl=62 time=24.4 ms --- 10.129.43.3 ping statistics --- 3 packets transmitted, 3 received, 0% packet loss, time 2014ms rtt min/avg/max/mdev = 23.721/25.331/27.833/1.792 ms
// breakdown
-c 3stop sending ICMP packets after 3 replies

Reachability is not the only thing the reply carries. The TTL is a cheap OS fingerprint: systems start it at a round number and each hop decrements it, so ttl=62 is a Linux host two hops away, while a value in the 120s points at Windows. It is a hint, not proof — the value can be tuned — but it costs nothing.

Observed TTLInitial valueLikely OS
60-6464Linux / Unix
120-128128Windows
250-255255Network appliance

When the host does not answer:

// shell
#ping -c 3 $TARGET_IP
PING 10.129.43.3 (10.129.43.3) 56(84) bytes of data. From 192.168.0.254 icmp_seq=1 Destination Host Unreachable From 192.168.0.254 icmp_seq=2 Destination Host Unreachable From 192.168.0.254 icmp_seq=3 Destination Host Unreachable --- 10.129.43.3 ping statistics --- 3 packets transmitted, 0 received, +3 errors, 100% packet loss, time 2010ms

Silence proves nothing on its own — plenty of hosts simply drop ICMP. Two things to rule out, in order: the VPN (below), then ICMP filtering. If the tunnel is healthy and the host still does not answer, keep going and scan with -Pn, which tells nmap to skip its own ping check instead of declaring the host down.

VPN

Check the tunnel before blaming the target. The interface must exist and carry an address, and exactly one client should be running — two instances fight over the routes and the traffic ends up in the wrong tunnel.

// shell
#ip addr show tun0
// breakdown
tun0the interface the VPN client creates; "does not exist" means no tunnel
// shell
#pgrep -a openvpn
// breakdown
-aprint the full command line next to each PID, to tell instances apart

Kill everything and reconnect if more than one instance shows up — killall tears the tunnel down, so it is a repair step, never a diagnostic one.

// shell
#sudo killall openvpn sudo openvpn ~/Downloads/lab.ovpn

Nmap

Two passes. The first sweeps all 65535 TCP ports as fast as the link allows and answers only "what is open"; the second aims the expensive detection at that short list. Running -A across every port instead wastes a lot of time on closed ones.

// shell1. Full port sweep
#nmap -p- --min-rate 5000 -oN "$TARGET_NAME-ports.nmap" $TARGET_IP
// breakdown
-p-scan all 65535 TCP ports, not just the top 1000--min-rate 5000send at least 5000 packets per second-oNwrite normal-format output to a file

Then re-scan only the ports that came back, with service and script detection:

// shell2. Service scan
#nmap -p 22,80,55555 -sC -sV -oN "$TARGET_NAME.nmap" $TARGET_IP
// breakdown
-p 22,80,55555only the ports the sweep found open-sCrun the default NSE script set-sVprobe each open port for its service and version

Useful additions depending on what the first pass says:

  • -Pn — treat the host as up even if it ignores ICMP.
  • -A — everything -sC -sV does plus OS detection and traceroute; louder and slower, worth it once the port list is short.
  • -sU --top-ports 20 — UDP is never touched by a TCP scan, and services like SNMP or TFTP only live there.

A port reported as filtered rather than closed is worth noting: something is listening but a firewall stands in the way. It is often still reachable from the machine itself, which is what makes a server-side request forgery on another service so valuable.

Keyboard

search this vault⌘K / /
step the sidebarjk
open selected↵
switch browse mode123
switch vaultgv
toggle themet
close / clearesc
this help?
esc to close