Reconnaissance and OSINT

Reconnaissance is the first phase of any attack. Before exploiting a vulnerability, the attacker needs to know what the target looks like: what services are running, what domains and subdomains exist, who works there, and what technology is in use. The more information they gather, the more targeted and effective their attack will be.

Prerequisites

You should understand how attackers think and networking fundamentals.

Passive vs active recon

Passive recon does not touch the target. The attacker uses publicly available information only. The target has no way to detect this activity.

Active recon interacts with the target: port scans, directory brute-forcing, sending crafted requests. This can be detected in logs and by intrusion detection systems.

Type	Example	Detectable?
Passive	WHOIS lookup	✗
Passive	DNS record query	✗ (usually)
Passive	LinkedIn research	✗
Passive	Google dorks	✗
Active	Port scan (nmap)	✓
Active	Directory brute-force	✓
Active	Vulnerability scanning	✓

WHOIS

WHOIS provides registration information for domain names: who registered it, when, and their contact information (unless privacy protection is enabled).

whois example.com

Output:

Domain Name: EXAMPLE.COM
Registry Domain ID: 2336799_DOMAIN_COM-VRSN
Registrar: ICANN
Updated Date: 2024-08-14T07:01:38Z
Creation Date: 1995-08-14T04:00:00Z
Registrar Registration Expiration Date: 2025-08-13T04:00:00Z
Name Server: A.IANA-SERVERS.NET
Name Server: B.IANA-SERVERS.NET

Useful information: registrar, creation date, name servers. If WHOIS privacy is not enabled, you might also find the registrant’s name, email, and organization.

DNS enumeration

DNS records reveal the infrastructure behind a domain.

# A records (IP addresses)
dig example.com A +short

Output:

93.184.216.34

# MX records (mail servers)
dig example.com MX +short

Output:

10 mail.example.com.

# TXT records (often contain SPF, DKIM, verification tokens)
dig example.com TXT +short

Output:

"v=spf1 include:_spf.google.com ~all"
"google-site-verification=abc123..."

The SPF record tells us they use Google for email. The site verification token confirms Google services.

# NS records (name servers)
dig example.com NS +short

# Attempt zone transfer (should fail on properly configured servers)
dig axfr example.com @ns1.example.com

Subdomain enumeration

Subdomains reveal services the organization may not have intended to expose publicly.

# Using DNS brute-forcing (in a lab context)
# Tools: subfinder, amass, dnsrecon

# subfinder (passive enumeration)
subfinder -d example.com -silent

Output:

www.example.com
mail.example.com
vpn.example.com
staging.example.com
dev.example.com
admin.example.com
api.example.com

staging.example.com and dev.example.com are interesting. Development and staging environments often have weaker security.

Example 1: Enumerate subdomains using passive tools

Let’s use multiple passive sources to build a comprehensive subdomain list:

# Method 1: Certificate Transparency logs
curl -s "https://crt.sh/?q=%25.example.com&output=json" | \
  python3 -c "import sys,json; [print(d['name_value']) for d in json.load(sys.stdin)]" | \
  sort -u

Output:

admin.example.com
api.example.com
blog.example.com
dev.example.com
mail.example.com
staging.example.com
www.example.com

Certificate transparency logs contain every TLS certificate ever issued. If a subdomain has a certificate, it appears here.

# Method 2: Search engine results
# Google: site:example.com -www
# This finds pages indexed on subdomains

# Method 3: DNS brute-force with a wordlist (active)
# Using a common subdomain wordlist
for sub in www mail ftp vpn admin dev staging api test; do
    result=$(dig +short "$sub.example.com" 2>/dev/null)
    if [ -n "$result" ]; then
        echo "$sub.example.com -> $result"
    fi
done

Output:

www.example.com -> 93.184.216.34
mail.example.com -> 93.184.216.35
admin.example.com -> 10.0.0.50
dev.example.com -> 10.0.0.100

Notice: admin.example.com and dev.example.com resolve to private IPs (10.0.0.x). This means they are internal services that should not be accessible from the internet. If DNS is misconfigured and these records are public, an attacker knows the internal IP scheme.

Google dorks

Google’s advanced search operators can find sensitive files, exposed directories, and misconfigured services.

Example 2: Use Google dorks to find exposed files

⚠ Only use these techniques against domains you own or have permission to test.

# Find directory listings
site:example.com intitle:"Index of"

# Find exposed configuration files
site:example.com filetype:env OR filetype:conf OR filetype:ini

# Find login pages
site:example.com inurl:login OR inurl:admin OR inurl:dashboard

# Find exposed documents
site:example.com filetype:pdf OR filetype:doc OR filetype:xlsx

# Find error messages that leak information
site:example.com "Warning:" "mysql" filetype:php

# Find backup files
site:example.com filetype:bak OR filetype:sql OR filetype:tar.gz

# Find Git repositories
site:example.com inurl:.git

# Find exposed API documentation
site:example.com inurl:swagger OR inurl:api-docs

Common findings:

• .env files with database credentials and API keys
• .git directories that expose source code
• SQL dump files with user data
• Swagger/API documentation with internal endpoints
• Directory listings showing all files in a folder

Shodan

Shodan is a search engine for internet-connected devices. Instead of indexing web pages, it indexes banners from services (SSH, HTTP, FTP, databases, IoT devices).

# Search for a specific organization's infrastructure
# On shodan.io:
org:"Example Corp"

# Find exposed databases
port:27017 "MongoDB"

# Find exposed webcams
"Server: yawcam"

# Find specific software versions
"OpenSSH 7.4" port:22

Shodan reveals:

• What services and versions are exposed to the internet
• Default credentials on devices
• Misconfigured services (databases without auth, exposed admin panels)
• Geographic location of infrastructure

What defenders can do

Reduce your attack surface

# Audit your DNS for unnecessary public records
# Remove staging/dev subdomains from public DNS
# Use split-horizon DNS (different records for internal vs external)

# Check what Shodan sees about your organization
# https://www.shodan.io/search?query=org:"Your+Company"

Monitor for exposure

• Set up Google Alerts for your domain and sensitive terms
• Monitor certificate transparency for unauthorized certificates
• Use Shodan to audit your internet-facing services regularly
• Check for leaked credentials on haveibeenpwned.com

OPSEC for employees

• Limit technical details in job postings (do not list specific software versions)
• Train employees on what should not be shared publicly
• Review company GitHub repos for committed secrets (use tools like truffleHog or gitleaks)
• Limit LinkedIn details about internal infrastructure

What comes next

The next article covers Exploitation basics and CVEs, where you will learn how vulnerabilities are discovered, scored, and exploited.

For the OSINT perspective in a broader security context, see the attacker mindset article.