What Is OSINT and How Attackers Use It to Reconnaissance Your Organization

What attackers learn from LinkedIn:

• Org chart: Who reports to the CISO, who manages the SOC, who is the VP of Engineering: useful for targeted phishing (business email compromise) and for understanding the organizational context of the attack
• Employee turnover: Recently departed employees who had privileged access and may have taken data or credentials with them
• Technology stack: Engineers list tools on their profiles: "Experienced with CrowdStrike Falcon, Splunk, AWS, Terraform" tells an attacker exactly what the security stack looks like
• Skill gaps: A small security team with no cloud security specialists suggests cloud configuration reviews are low-priority

What attackers learn from job postings:

Job postings are unusually candid about internal technology:

Example job posting intelligence:
"Requirements: Experience with AWS (EC2, S3, RDS), Kubernetes (EKS), 
HashiCorp Terraform, Jenkins CI/CD, and our security tools 
(CrowdStrike Falcon, Qualys, Splunk SIEM)."

What this tells an attacker:
- AWS with specific services → look for exposed S3 buckets, IAM misconfigurations
- Jenkins → check for exposed Jenkins console
- CrowdStrike → attacker needs to evade a specific EDR
- Qualys → vulnerability scanning is in place, known CVEs may be patched
- Splunk → SIEM is in place: attacker needs to minimize event generation

Defensive steps:

• Audit your own job postings: specify technology categories ("cloud infrastructure") rather than specific products ("AWS EKS, Terraform 1.6")
• Review LinkedIn employee profiles for disclosed internal tools: they are not required to list internal tool names; most will remove this if asked
• Implement a social engineering awareness program: employees should know that tool disclosure on social media is a reconnaissance vector

Passive DNS and certificate transparency:

Certificate transparency logs are public databases of every TLS certificate ever issued. Every subdomain you have ever given a certificate to is discoverable:

# Using crt.sh to enumerate subdomains via certificate transparency
curl -s 'https://crt.sh/?q=%.example.com&output=json' | 
  jq -r '.[].name_value' | 
  sort -u | 
  grep -v '^\*'

# Using amass for comprehensive subdomain enumeration
amass enum -passive -d example.com -o subdomains.txt

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

Typical findings from certificate transparency searches:

• dev.example.com: development environment, may be less patched
• staging.example.com: staging environment with production-like access
• jenkins.example.com: CI/CD server, should not be public-facing
• vault.example.com: secrets management, should not be public-facing
• admin.example.com: administrative interface
• vpn.example.com: VPN endpoint, version disclosure may reveal unpatched software

Shodan and Censys: indexing exposed services:

# Search Shodan for all services associated with an organization
shodan search 'org:"Example Corporation" -H

# Find specific vulnerable services
shodan search 'product:Jenkins hostname:example.com'
shodan search 'http.title:"GitLab" hostname:example.com'
shodan search 'ssl:example.com port:8080'

# Look at what Shodan sees for your IP ranges
shodan host 203.0.113.100

Shodan continuously crawls the internet and indexes service banners, including software version numbers. An exposed Confluence server showing Atlassian Confluence 8.1.0 tells an attacker exactly which CVEs apply.

Run your own passive reconnaissance first:

# What does your organization look like from the outside?
# Run these against your own domains before attackers do
amass enum -d example.com -o recon/subdomains.txt
shodan search "org:Example Corporation"
curl -s 'https://crt.sh/?q=%.example.com&output=json' | jq -r '.[].name_value' | sort -u
nmap -sV -p 80,443,8080,8443,22,3389 $(cat recon/subdomains.txt | head -50)

What leaks into public GitHub repositories:

• API keys and secrets committed accidentally
• Internal hostnames, IP addresses, and service endpoints in config files
• AWS account IDs, GCP project IDs
• Database connection strings with credentials
• SSH private keys
• .env files committed before adding to .gitignore
• Internal documentation in README files

Search GitHub for your organization's secrets:

# TruffleHog: scan for high-entropy strings and known credential patterns
trufflehog github --org=ExampleCorp --only-verified

# Gitleaks: scan a repository
gitleaks detect --source ./repo --verbose

# GitHub dork searches (manually or via API)
# site:github.com "example.com" password
# site:github.com "example.com" "api_key"
# site:github.com org:examplecorp filename:.env
# site:github.com org:examplecorp "aws_access_key_id"

Tools attackers use and defenders should run first:

# GitGuardian (free for open source)
# Scans public GitHub for your organization's secrets
# Sign up and add your domain to receive alerts when secrets leak

# truffleHog: run against all your public repos
for repo in $(gh repo list ExampleCorp --json name -q '.[].name'); do
  echo "Scanning $repo..."
  trufflehog github --repo=https://github.com/ExampleCorp/$repo --only-verified 2>/dev/null
done

Defensive steps:

• Add pre-commit hooks that scan for secrets before commit (gitleaks, git-secrets)
• Enable GitHub secret scanning on all repositories
• Configure push protection to block pushes containing detected secrets
• Run TruffleHog or GitGuardian against all existing public repos: rotate any exposed credentials immediately

Have I Been Pwned and breach databases:

Multiple data breach databases contain billions of employee email/password combinations from past breaches of other services. Attackers use these to:

1. Credential stuffing: try breach passwords against your VPN, email, and SSO
2. Password spraying: use common passwords from breach data against all employee accounts
3. Context building: knowing an employee's personal email and past passwords reveals patterns

# Check your organization's email domain against HIBP
# Register your domain at haveibeenpwned.com for free breach notifications
curl -s 'https://haveibeenpwned.com/api/v3/breachesforaccount/employee@example.com' \
  -H 'hibp-api-key: YOUR_API_KEY' | jq '.[].Name'

# Bulk domain check (via HIBP API or paid service)
# SpyCloud, Flare, and Constella Intelligence provide enterprise breach monitoring

Dehashed and other paid breach databases:

Beyond HIBP, paid services index plaintext passwords from breaches. Attackers often subscribe to these. Defenders should also check:

• DeHashed (subscription service)
• Intelligence X
• Leaked.site

The defensive response to breach exposure:

# Force password reset for all accounts found in breach data
# For Azure AD / Entra ID:
Get-AzureADUser -Filter "mail eq 'exposed-user@example.com'" | 
  Set-AzureADUserPassword -ForceChangePasswordNextLogin $true

# Enable MFA for all accounts: breach passwords become useless with MFA
# This is the single highest-impact control for credential stuffing prevention

Pastebin, dark web, and telegram OSINT:

Attackers monitor paste sites and dark web forums for leaked credentials, internal documents, and breach announcements. Defensive monitoring:

• DarkOwl, Flashpoint, Recorded Future: commercial dark web monitoring
• Pulsedive: free threat intelligence for domain/email monitoring
• OSINT Industries: free tier for searching leaked data

Reduce your OSINT exposure: