nmap, OSINT, and the art of being loud without realising it
You sit down at the exam terminal. First task. You have an IP address and a domain name. The clock is ticking. Your brain is asking: what do I run first?
I froze there for a good two minutes. Not panicking — just caught between too many options. Nmap? Gobuster? theHarvester? Google dorking? Trial-and-error mode kicked in. And that’s exactly what I want to write about: why recon is both the easiest phase and the one that reveals your mindset. Especially if you’re a SOC analyst pretending to be an attacker.
From the attacker terminal#
You start with scanning.
nmap -sC -sV -O <target>
Default scripts, version detection, OS fingerprint. It gives you open ports, running services, maybe a hostname. If you’ve done labs, this is muscle memory.
But there are quieter scans. -sS (SYN stealth) instead of full TCP connect. Fragmenting packets with -f if the firewall is jumpy. And there are louder scans — -A throws everything at once and screams.
For OSINT on the domain, you’d run:
theHarvester -d example.com -b google,linkedin
dnsrecon -d example.com -t std
whois example.com
And if you want to go full Google-dork:
site:example.com filetype:pdf "confidential"
intitle:"index of" "parent directory"
These are all standard. Well-documented. Nobody gets points for creativity — you get points for coverage. Miss a subdomain, a hidden file, an exposed email, and you might miss the foothold.
What tripped me up was tool selection, not tool use. I’d run a scan, wait, wonder if it was the right scan, run another, waste time. The lesson: have a sequence. Know what to run first and why. That’s the difference between chaos and control in a 6-hour window.
From the SOC side#
Now flip the wire. I do this every day.
An nmap SYN scan lights up the SIEM like a Diwali cracker — but only if your sensors are placed right. You’ll see:
- Multiple TCP SYN packets from one source to multiple destination ports in a short window (scanner detection rule).
- Alerts like “ET SCAN NMAP OS Detection Probe” or “Port Scan Detected” in Suricata / Snort.
- Firewall logs showing denied connections on closed ports.
But here’s the catch: a slow scan with -T1 or -T2, maybe fragmented, might not trigger the same thresholds. The SOC sees a trickle of noise, not a flood. So when I run nmap in an exam, I’m thinking: is my scan pattern loud enough to trip my own monitoring stack? It’s a weird mental loop.
OSINT is quieter — it rarely hits the target’s network directly. TheHarvester, dnsrecon, whois queries go to public servers (Google, DNS resolvers). Your SOC won’t see them unless you’re monitoring outbound DNS or proxy logs heavily, and even then, they look like regular lookups. Google dorking? Just HTTP requests. No exploits. The only red flag is if someone later finds the exposed files because you clicked them.
But if your SOC is mature, you might catch:
- Excessive DNS TXT/MX queries from a single internal host (possible recon via DNS).
- A user agent string like
theHarvester/4.0in proxy logs — yes, some tools are that polite.
Most SOCs don’t catch OSINT. That’s worth remembering: the attacker’s earliest footsteps are often invisible. And that’s exactly why defenders should learn them.
How this played out in the exam#
I had a domain and an IP. My brain wanted to run everything at once. Instead, I forced myself to breathe and follow a fixed sequence: whois → dnsrecon → theHarvester → Google dork → nmap. Not because it’s the best sequence, but because it’s a sequence. A rhythm that prevents thrash.
And when I saw an open port 80 with a directory listing I found through dorking, I didn’t need to scan further for that vector. I had my foothold.
The SOC voice in my head kept whispering: “that nmap scan just tripped three rules.” But I wasn’t in a SOC. I was the attacker. I let it be loud. Maximum effort, remember? Not maximum stealth. The exam doesn’t care about quiet.
The two-sides takeaway#
Recon isn’t just step one. It’s the phase where you decide what kind of operator you are — methodical or messy. If you’re a defender learning this, the gift is that you start to understand what your sensors miss, and what they catch. You might even tune your alerts differently after walking the walk.
Next post: scanning deeper — service enumeration, banner grabbing, and what that noise looks like before an attack.
Tools used
nmap -sC -sV -O→ aggressive service/OS scan (triggers scanner detection in IDS)nmap -sS -T2→ stealthy SYN scan, slower (may slip under radar)theHarvester→ email/subdomain OSINT (invisible to target, leaves user-agent traces in proxy logs)dnsrecon→ DNS enumeration (visible only if monitoring DNS queries)whois→ domain registration info (completely passive)- Google dorking → exposed files/dirs (HTTP requests, normal traffic unless content is sensitive)
