recon • August 02, 2026 • 5 min read (1084 words)

Reconnaissance & OSINT: mapping a target before touching it

How internet-wide scanners work, the legal boundary in India, and why opting out of Shodan doesn't actually protect anything.

Why Recon Comes First

Every major attack framework treats reconnaissance as its own distinct phase: MITRE ATT&CK calls it Reconnaissance, the Lockheed Martin Cyber Kill Chain calls it the same, PTES calls it Information Gathering. The core insight worth internalizing: the overwhelming majority of a real attack isn’t “hacking” in the dramatic sense — it’s patient, mostly legal information-gathering from data that’s already public. The actual exploitation step is usually the smallest part of the operation.

How Attackers Find Vulnerable Machines at Internet Scale

They don’t guess — they scan systematically:

  1. Port scanning (Nmap, Masscan) — sends packets across huge IP ranges to see which ports respond, revealing what services are running and reachable.
  2. Banner grabbing — many services announce their own exact version in response to a connection (e.g., “OpenSSH 7.2,” “Apache 2.4.6”). That version is then cross-referenced against known CVE databases.
  3. Shodan / Censys / ZoomEye — search engines that continuously scan the entire internet in the background and index what they find, letting anyone query it like Google (e.g., org:"Company Name" or a specific software version + country). This removes the need to scan anything yourself.
  4. Vulnerability scanners (Nessus, OpenVAS, Nuclei) — actively probe a target against hundreds of known CVE signatures and return a report of confirmed weaknesses.
  5. Mass/opportunistic scanning — worms like WannaCry didn’t target anyone specifically; they scanned the entire IPv4 space (~4.3 billion addresses, computationally trivial) looking for any reachable vulnerable service. This is why “nobody would target me” is the wrong mental model — automated scanners aren’t personal.

Mapping an Organization’s Full Attack Surface

Knowing which IPs belong to a company at all is its own discipline, built almost entirely from public records:

  • WHOIS / regional registries (ARIN, RIPE, APNIC) — reveal IP blocks (CIDR ranges) a company owns outright.
  • BGP / ASN lookups (bgp.he.net, bgp.tools) — large organizations that run their own infrastructure have an Autonomous System Number; searching it reveals every IP range announced under that org’s name.
  • Reverse DNS and subdomain enumeration (Sublist3r, Amass, Subfinder) — brute-force and crawl for subdomains, each one another data point mapping the organization’s footprint.
  • Certificate Transparency logs (crt.sh) — every HTTPS certificate issued is publicly logged; searching %.company.com frequently surfaces internal, staging, or dev subdomains nobody intended to expose.
  • Cloud metadata and OSINT — job postings, SEC filings, and press releases often leak details about tech stack and infrastructure changes.

None of this requires breaking any law — it’s DNS, certificate logs, and registries that exist publicly by design. The skill is not finding any single data point; it’s correlating many individually-boring facts into a usable attack path (e.g., IP range → subdomain → outdated CMS on a staging server → a leaked credential on GitHub tied to that same server).

This is the line that separates reconnaissance (generally legal, or at least widely tolerated) from unauthorized access (a crime):

  • Passive scanning/banner-grabbing sends the same kind of request a browser sends visiting a website — it doesn’t exploit anything or bypass authentication.
  • The crime begins at the point of acting on what recon reveals: logging into a system without permission, exfiltrating data, exploiting a flaw.
  • India specifically is stricter on paper than many jurisdictions: under Section 43 of the IT Act, 2000, unauthorized access without prior written permission — port scanning included — is treated as a civil contravention, with Section 66 escalating it to a criminal offense (up to 3 years imprisonment) if done with fraudulent intent. This is a real gap between the letter of the law and how it’s enforced in practice, since foreign scanning services operate largely outside India’s practical enforcement reach — but it matters directly for any authorized security work: written scope authorization isn’t optional, it’s the legal difference between research and a crime.

Why “Opting Out” of Shodan Doesn’t Actually Protect Anything

An important realization: removing a company from Shodan’s index does nothing to the underlying exposure.

  • Shodan is one indexer sitting on top of internet-wide scanning — anyone can still run their own scan directly against the same IP in seconds, opt-out or not.
  • Multiple competing scanners exist independently (Censys, ZoomEye, FOFA, BinaryEdge) — a company would need to opt out of all of them, and new ones keep appearing.
  • Attackers running targeted operations don’t rely on any third-party index existing at all; they scan the target directly, or use botnets of already-compromised devices to do it for free at scale.
  • The actual fix is closing the exposure, not hiding from the index that reports it — this is the core lesson: security through obscurity is not a real defense. Security through actual configuration (patching, closing ports, disabling default credentials) is.

Planning an Attack Against a Hardened Target

Most real targets aren’t running fifteen exposed services — often it’s just SSH and HTTP/HTTPS. Against a minimal surface like this, the strategy shifts from width to depth:

SSH (22): Rarely a software exploit target since vulnerabilities get patched fast. Instead: credential brute-forcing/spraying, checking for leaked private keys accidentally committed to public repos, and version fingerprinting against known CVEs (e.g., the 2024 “regreSSHion” RCE).

HTTP/HTTPS (80/443): Usually where the real attack surface is, because it’s a full application, not just a protocol — technology fingerprinting (Wappalyzer, WhatWeb) to identify exact CMS/framework versions, directory brute-forcing (gobuster, ffuf) for hidden admin panels or leftover backup files, and application-layer bugs (SQL injection, XSS, IDOR, auth bypass) that exist independently of how well-patched the underlying OS is.

If both are genuinely hardened, attackers pivot away from the network layer entirely:

  • Supply chain compromise (attack the vendor who pushes trusted updates — the NotPetya pattern)
  • Social engineering / phishing (steal an employee’s legitimate credentials rather than exploit the server)
  • Third-party/vendor pivot (attack a smaller, less-secured partner with trusted access)
  • Client-side attacks (target the users of a web app instead of its infrastructure)

Core Takeaway

A hardened server with only two open ports isn’t “unattackable” — it just forces the attacker up the stack, from the network layer into the application and human layers, which is exactly where most real breaches actually happen. This is also why modern defense has shifted so heavily toward credential monitoring, phishing awareness, and supply-chain auditing rather than only perimeter hardening — the network perimeter got hard enough that attackers mostly stopped kicking down the front door and started looking for side doors instead.

Comments

Discuss via GitHub — requires Discussions enabled on Dev-Lahrani/resume-website. If disabled, this shows a placeholder.