Network recon utilities

In a nutshell Before you "hack" anything, you need to learn basic things about the target: is it even alive? which path does traffic take to it? who owns its domain? what are its network settings? For that there are four classic commands — ping, traceroute, whois, dig. They're simple, but every bit of recon starts with them. All four ship with Kali out of the box.

First — an important distinction that runs through the whole profession.

Passive and active recon

Reconnaissance (recon) is gathering information about a target. It comes in two kinds, and the difference is fundamental:

• Passive — you collect what's in open sources without touching the target itself. The target doesn't even learn you're interested. Example: looking up who owns a domain in whois — that data is held by the registrar, not on the target's server.
• Active — you contact the target's system directly and leave traces in its logs. Example: ping or a port scan — you knock on the server itself, and it sees it.

Why it matters: in real work (and by law) active actions require permission, passive ones usually don't. And tactically: you squeeze the most out of passive first, so as not to "show up" earlier than needed.

Of our four utilities: whois and dig are usually passive recon (we query third-party databases), ping and traceroute are active (we touch the target directly).

ping — "are you alive?"

The simplest and most frequent command. It sends the target a small service packet (an ICMP Echo Request) and waits for a reply (Echo Reply). If a reply comes back — the host is reachable, and you also see how many milliseconds it took to answer (latency).

Analogy: shout "Hey!" and wait for an "Over here!" back. Echo returned — someone's there, and from the round-trip time you can tell how far.

ping tryhackme.com          # sends packets until you press Ctrl+C
ping -c 4 10.10.10.10       # exactly 4 packets, then exit (-c = count)

What to read in the output:

• time=23 ms — latency. The smaller, the "closer" the host over the network. 20–70 ms is normal; hundreds of ms means far away or a poor link.
• 0% packet loss — every packet arrived. If there's loss (say 20% loss) — the link is unstable.
• TTL=64 in the reply — how many "hops" the packet has left to live (see traceroute below); from the initial TTL you can sometimes guess the OS (Linux is usually 64, Windows 128).

Silence ≠ dead host A very common beginner mistake: ping didn't answer → "host is off, move on." That's wrong. Many firewalls deliberately block ICMP while the server itself works fine and serves sites. On a pentest, never write a target off on a single silent ping — check the ports (nmap) separately.

A handy trick — checking the MTU (the largest packet size that passes without fragmentation):

ping -s 1472 -M do target   # -s size, -M do = "don't fragment"

If packets that size don't pass but smaller ones do, there's a small MTU somewhere along the path. This, by the way, is one of the typical causes of "the TLS handshake hangs" in VPN problems.

traceroute — "which path do I take to reach you?"

Shows all the intermediate routers (hops) on the path from you to the target. So not just "arrived / didn't arrive," but the whole route: which nodes the traffic runs through and at which one it might be getting stuck.

How it even works (neatly designed). Every packet has a life counter — TTL (Time To Live). At each router it drops by 1, and when it hits zero the router discards the packet and sends back a "your packet died here" message. traceroute exploits this: first it sends a packet with TTL=1 (it dies at the first router — which introduces itself), then TTL=2 (dies at the second), then TTL=3, and so on. Collecting these "introductions," the command builds a full map of the route.

Analogy: you want to learn the road to a city, so you send couriers with food for 1 day, 2 days, 3 days. The first reaches the first town and collapses there — from which they send word "your courier reached us." The second collapses in the second town. That's how you learn the whole chain of towns along the way.

traceroute tryhackme.com
traceroute -n target        # -n = don't resolve IPs to names (faster, no DNS delays)
traceroute -I target        # via ICMP (by default traceroute sends UDP)
traceroute -T -p 443 target # via TCP on port 443 — gets through where UDP/ICMP is filtered

What to read:

• Each line is one hop: the number, the router's address and the time (usually three probes).
• * * * on a line — that router didn't answer. This is normal, not a fault: many nodes are set to stay silent. If the asterisks run all the way to the end and the target never appears — then the traffic really is stopping somewhere.
• A sharp jump in time between two hops shows where the "bottleneck" or the boundary of a distant network is.

On Windows the same command is called tracert.

whois — "who owns this domain?"

When someone registers a domain (e.g. tryhackme.com), the registration data goes into a public database. whois queries that database and shows: who the registrar is, when the domain was created and when it expires, what its DNS servers are, and sometimes the owner's contacts.

Analogy: a property registry. You don't enter the house itself — you look in the public book: who the owner is, when it was bought, through which agency.

whois tryhackme.com

What to look for through an attacker's/analyst's eyes:

• Creation Date — the domain's age. A domain registered three days ago, in a phishing investigation, is an instant red flag: real companies sit on their domains for years.
• Registrar — who it's registered through (NameCheap, GoDaddy…).
• Name Server (the DNS servers) — very useful. If it's, say, *.CLOUDFLARE.COM, then the domain hides behind Cloudflare and the server's real IP isn't easily seen.
• Contacts — often hidden by a privacy service (WhoisGuard, Privacy Protect). That's normal, not "lucky/unlucky."

whois is almost always passive recon: you're asking the registrar's database, not the target's server.

dig — "what does DNS say about this site?"

DNS is the system that turns a friendly name (google.com) into an IP address (142.250.185.78), because computers talk over addresses while people remember names. dig (Domain Information Groper) is the precise tool for asking DNS about anything by hand. There's a simpler one — nslookup (present even on Windows) — but dig is more flexible and shows more.

Analogy: a phone book. You know the name ("Ivan Petrov") but need the number. dig is a query to directory assistance: "give me every contact filed under this name."

dig tryhackme.com              # A record: the domain's IPv4
dig tryhackme.com +short       # just the answer, without the service wall of text
dig tryhackme.com MX           # the domain's mail servers
dig tryhackme.com NS           # which DNS servers serve the domain
dig tryhackme.com TXT          # text records (often mail settings, verifications)
dig @8.8.8.8 tryhackme.com     # ask a specific DNS (here — Google 8.8.8.8)
dig -x 1.1.1.1                 # reverse lookup: from an IP get the name

DNS record types you'll meet (a detailed breakdown is in How DNS works):

Why it helps in recon: from the MX records you learn what mail the target uses; NS records reveal the DNS provider; sometimes subdomains and services the company forgot about "stick out" in DNS.

What order to use these in

The usual sequence at the start of working a target:

1. whois + dig — passively, without touching the target yet. Learn the owner, the domain's age, the IP, the mail, the DNS servers. The target notices nothing.
2. ping — is there a connection at all, is the host alive, what's the latency. (Remember: silence isn't a verdict.)
3. traceroute — how traffic runs to the target, where the network boundaries and possible filters are.
4. Then already nmap — which ports are open and what services sit behind them. That's the next, "louder" step of recon.