DΛΣMӨП

ENUM ^: Enumeration

Cheatsheet - Infrastructure Enumeration Tools 1

curl -s "https://crt.sh/?q=TARGET.com&output=json" | jq -r '.[].name_value' | sort -u

intermediate updated 2026-08-10 Gitleaks · TruffleHog
#enumeration

Basic query — good starting point

curl -s “https://crt.sh/?q=TARGET.com&output=json” | jq -r ’.[].name_value’ | sort -u

Output

*.TARGET.com admin.TARGET.com blog.TARGET.com mail.TARGET.com vpn.TARGET.com www.TARGET.com


> [!info]+ Command Breakdown
> 1. **jq -r '.[].name_value'** — extracts ONLY the `name_value` field from every array entry using `-r` (raw output, no quotes)
> 2. This is cleaner than the `grep | cut | awk` chain in the original notes — fewer failure points
> 3. **sort -u** — deduplicates; wildcard entries like `*.TARGET.com` are preserved as-is

---

```bash
# Strip wildcards and get clean hostnames only
curl -s "https://crt.sh/?q=TARGET.com&output=json" \
  | jq -r '.[].name_value' \
  | sed 's/\*\.//g' \
  | sort -u \
  | grep -v "^TARGET.com$" > subdomains.txt

cat subdomains.txt
admin.TARGET.com
blog.TARGET.com
mail.TARGET.com
vpn.TARGET.com
www.TARGET.com

[!info]+ Command Breakdown

  1. sed ‘s/*.//g’ — strips the *. wildcard prefix to leave a clean hostname
  2. grep -v “^TARGET.com$” — removes the bare root domain from the list (you already know it)
  3. > subdomains.txt — saves to file for use in the next steps (host loop, Shodan loop)
  4. This output feeds directly into the host bulk resolution loop
# Query for EXPIRED certs too — these reveal old subdomains that may still be live
curl -s "https://crt.sh/?q=%25.TARGET.com&output=json" | jq -r '.[].name_value' | sort -u

[!info]+ Command Breakdown

  1. %25.TARGET.com — URL-encoded % wildcard; matches ALL subdomains ever issued a cert, including expired ones
  2. Expired subdomains are often forgotten by admins — they may still resolve and run old, unpatched services
  3. Cross-reference this list against your host resolution output to see which old subdomains are still live

[!warning]+ crt.sh Gotchas

  1. Results include third-party issued certs — a subdomain listed here is NOT guaranteed to be company-owned infrastructure
  2. Wildcard certs (*.TARGET.com) confirm the domain uses wildcard SSL but don’t enumerate actual subdomains — use other methods to enumerate what lives under the wildcard
  3. Rate limiting — if querying many domains, add sleep 2 between requests or use the Shodan/Subfinder pipeline instead
  4. Results can lag by hours after a new cert is issued — not real-time

curl + jq — API Querying and JSON Parsing

[!tip]+ jq is More Powerful Than Used in the Notes The original notes use jq . (pretty print only). Here are more useful filters:

# Extract only specific fields — issuer + subdomain + expiry
curl -s "https://crt.sh/?q=TARGET.com&output=json" \
  | jq -r '.[] | [.issuer_name, .name_value, .not_after] | @tsv'

# Output (tab-separated)
C=US, O=Let's Encrypt, CN=R3    mail.TARGET.com    2025-12-01T00:00:00
C=US, O=Cloudflare, Inc.        www.TARGET.com     2026-01-15T00:00:00

[!info]+ Command Breakdown

  1. ’.[] | …’ — iterates over every element in the array
  2. [.issuer_name, .name_value, .not_after] — selects three specific fields into an array
  3. @tsv — formats the array as tab-separated values — easy to cut, grep, or import into a spreadsheet
  4. The issuer column immediately tells you if a subdomain uses Cloudflare, Let’s Encrypt, DigiCert etc. — Cloudflare = WAF/proxy likely in front
# Count how many unique subdomains exist
curl -s "https://crt.sh/?q=TARGET.com&output=json" | jq '[.[].name_value] | unique | length'

# Output
47

[!info]+ Command Breakdown

  1. [.[].name_value] — collects all name values into a new array
  2. unique — deduplicates the array
  3. length — returns the count
  4. Use this as a quick “how big is the attack surface” indicator before diving in

[!tip]+ curl Best Practices

  1. Always use -s (silent) to suppress the progress bar — it pollutes piped output
  2. Add -A “Mozilla/5.0” to spoof a browser User-Agent if a service rejects curl requests
  3. Use -o /dev/null -w ”%{http_code}” to test if a URL is reachable without dumping the body
  4. Add —max-time 10 to prevent curl hanging indefinitely on slow hosts

dig — DNS Enumeration

[!tip]+ Query Specific Record Types — Don’t Always Use ANY Many resolvers block or ignore dig any queries. Query record types directly for reliable results:

# A records — IPv4 addresses
dig A TARGET.com +short

# AAAA records — IPv6 addresses
dig AAAA TARGET.com +short

# MX records — mail servers
dig MX TARGET.com +short

# NS records — name servers
dig NS TARGET.com +short

# TXT records — the intelligence goldmine
dig TXT TARGET.com +short

# SOA record — primary DNS authority
dig SOA TARGET.com +short

# CNAME — canonical name (reveals CDN, load balancer names)
dig CNAME www.TARGET.com +short

[!info]+ Command Breakdown

  1. +short — suppresses all header/footer output, returns only the answer — much cleaner than default output
  2. Query each record type separately — dig any often returns incomplete or filtered results from modern resolvers
  3. CNAME records are especially useful — they often reveal the CDN or load balancer in use (e.g., target.cloudflare.net, target.azurefd.net)
  4. MX pointing to Google = Google Workspace. MX pointing to outlook.com = Microsoft 365. Both have implications for cloud access.
# Use a specific DNS resolver — bypass internal resolver caching
dig TXT TARGET.com @8.8.8.8 +short    # Google
dig TXT TARGET.com @1.1.1.1 +short    # Cloudflare
dig TXT TARGET.com @9.9.9.9 +short    # Quad9

[!info]+ Command Breakdown

  1. @8.8.8.8 — directs the query to a specific resolver instead of your system’s default
  2. Use this when your local resolver returns stale/cached results or when testing from behind a corporate network
  3. Comparing responses between resolvers can reveal split-horizon DNS — different answers for internal vs external queries
  4. Split-horizon DNS is a strong indicator of an internal network — note it for the Gateway layer
# Attempt a zone transfer — almost always fails externally but worth trying
dig AXFR TARGET.com @ns.TARGET.com

# If it works, output dumps ALL DNS records at once:
; <<>> DiG 9.16.1-Ubuntu <<>> AXFR TARGET.com @ns.TARGET.com
TARGET.com.        3600    IN    SOA    ns1.TARGET.com. hostmaster.TARGET.com.
admin.TARGET.com.  3600    IN    A      10.10.10.5
dev.TARGET.com.    3600    IN    A      10.10.10.12
vpn.TARGET.com.    3600    IN    A      10.10.10.1

[!info]+ Command Breakdown

  1. AXFR — DNS zone transfer request; asks the name server to send ALL records for the zone
  2. Requires knowing the authoritative NS server — get this from dig NS TARGET.com +short first
  3. Modern DNS servers reject AXFR from untrusted IPs, but misconfigured or older servers may allow it
  4. A successful zone transfer is a critical finding — it immediately hands you the entire internal DNS map

[!warning]+ dig vs host vs nslookup

ToolBest ForAvoid When
digFull record queries, scripting, verbose outputYou just need a quick IP lookup
hostFast bulk lookups, simple A record resolutionYou need specific record types or JSON output
nslookupWindows environmentsScripting — its output format is inconsistent

host — Bulk Subdomain Resolution

[!tip]+ Going Further Than the Notes

# Reverse DNS lookup — IP to hostname
host 10.129.24.93
93.24.129.10.in-addr.arpa domain name pointer blog.TARGET.com.

[!info]+ Command Breakdown

  1. Pass an IP address to host instead of a hostname for reverse lookup
  2. Reveals hostnames you may not have found in forward DNS enumeration
  3. Run this on every IP returned by Shodan — you may discover additional virtual hosts pointing to the same IP
# Query a specific record type with host
host -t MX TARGET.com
host -t TXT TARGET.com
host -t NS TARGET.com

[!info]+ Command Breakdown

  1. -t [TYPE] — specifies the record type to query
  2. Output is simpler than dig — useful for quick checks but less detail
  3. Use dig for full output with TTL and authority sections; use host -t for fast piped workflows
# Better bulk resolution loop — saves both hostname and IP, skips failed lookups
while read subdomain; do
  result=$(host "$subdomain" 2>/dev/null | grep "has address" | awk '{print $1, $4}')
  [ -n "$result" ] && echo "$result"
done < subdomains.txt | tee resolved.txt

# Output
blog.TARGET.com 10.129.24.93
mail.TARGET.com 10.129.127.22
www.TARGET.com 10.129.127.33

[!info]+ Command Breakdown

  1. while read subdomain — cleaner than for i in $(cat file) — handles spaces in lines safely
  2. 2>/dev/null — suppresses error output for subdomains that don’t resolve
  3. [ -n “$result” ] — only prints if the result is non-empty (skips dead subdomains silently)
  4. tee resolved.txt — prints to terminal AND saves to file simultaneously
  5. resolved.txt becomes your definitive list of live, company-hosted targets for active testing

Shodan — Passive IP and Service Intelligence

[!important]+ Setup First — Easy to Skip

# Install the Shodan CLI
pip3 install shodan

# Initialise with your API key (free account works for basic queries)
shodan init YOUR_API_KEY_HERE

# Verify it works
shodan info
# Output:
# Query credits available: 100
# Scan credits available: 0

[!info]+ Command Breakdown

  1. shodan init — stores your API key locally so you don’t have to pass it every command
  2. Free accounts get 100 query credits — enough for a standard engagement’s passive recon
  3. Get your API key at https://account.shodan.io/ — just needs a free registration
# The basic host lookup from the notes
shodan host 10.129.24.93

# Better: search by organisation name — finds ALL IPs registered to the company
shodan search --fields ip_str,port,org,hostnames "org:\"InlaneFreight\""

# Output
10.129.24.93    80      InlaneFreight   blog.inlanefreight.com
10.129.27.33    443     InlaneFreight   www.inlanefreight.com
10.129.127.22   25      InlaneFreight   matomo.inlanefreight.com

[!info]+ Command Breakdown

  1. “org:“InlaneFreight"" — Shodan search filter for organisation name; quotes inside the string are escaped
  2. —fields ip_str,port,org,hostnames — limits output to only the useful columns
  3. This finds IPs you may have missed entirely in DNS enumeration — Shodan indexes based on what it scans, not what DNS says
# Find all subdomains Shodan has seen for a domain
shodan search --fields ip_str,port,hostnames "hostname:TARGET.com"

# Find only SSL-enabled services — check for weak ciphers
shodan search "hostname:TARGET.com ssl.version:TLSv1"

# Find specific open ports across the org
shodan search "org:\"InlaneFreight\" port:22"
shodan search "org:\"InlaneFreight\" port:3389"   # RDP — always worth noting
shodan search "org:\"InlaneFreight\" port:445"    # SMB — goldmine

# Find services with default/vendor credentials (Shodan tags these)
shodan search "org:\"InlaneFreight\" has_screenshot:true"

[!info]+ Command Breakdown

  1. hostname:TARGET.com — finds all IPs where Shodan has observed the domain in the SSL cert or reverse DNS
  2. ssl.version:TLSv1 — filters for hosts still running deprecated TLS 1.0 — a vulnerability
  3. port:3389 / port:445 — RDP and SMB exposed to the internet are high-priority findings
  4. has_screenshot:true — Shodan captures screenshots of HTTP services — you can see login panels, admin interfaces, and dashboards without sending a single packet to the target

[!tip]+ Shodan Filters Quick Reference

FilterExampleWhat It Finds
org:org:"Target Corp"All IPs registered to that organisation
hostname:hostname:target.comIPs with that hostname in cert/DNS
port:port:22Services on a specific port
country:country:GBRestrict by country
ssl.version:ssl.version:TLSv1Weak SSL/TLS versions
product:product:ApacheSpecific software
os:os:"Windows Server 2016"Specific OS versions
has_screenshot:has_screenshot:trueServices with captured screenshots
http.title:http.title:"Login"Pages with specific HTML titles

Google Dorks — Cloud and File Discovery

[!tip]+ Beyond the Basic inurl/intext Combo The notes cover inurl: and intext:. Here is the full operator toolkit:

# Find exposed files by type on the company's domain
site:TARGET.com filetype:pdf
site:TARGET.com filetype:xlsx
site:TARGET.com filetype:docx
site:TARGET.com filetype:env
site:TARGET.com filetype:sql
site:TARGET.com filetype:log

[!info]+ Command Breakdown

  1. site:TARGET.com — restricts ALL results to the specified domain and its subdomains
  2. filetype: — filters by file extension — find documents, spreadsheets, SQL dumps, log files
  3. .env files indexed by Google are an instant win — they almost always contain secrets
  4. .sql files may contain database dumps with credentials and PII
# Find login panels and admin interfaces
site:TARGET.com intitle:"login"
site:TARGET.com intitle:"admin"
site:TARGET.com inurl:"/admin"
site:TARGET.com inurl:"/wp-admin"
site:TARGET.com inurl:"/phpmyadmin"
site:TARGET.com inurl:"/dashboard"

[!info]+ Command Breakdown

  1. intitle: — searches the HTML <title> tag of pages — login panels almost always say “Login” in their title
  2. inurl: — searches the URL path — admin panels follow predictable URL patterns
  3. Combine site: with intitle: for targeted results with zero noise
# Cloud storage discovery — go beyond the notes
intext:"TARGET" inurl:amazonaws.com
intext:"TARGET" inurl:blob.core.windows.net
intext:"TARGET" inurl:storage.googleapis.com
intext:"TARGET" inurl:s3.amazonaws.com
intext:"TARGET" inurl:digitaloceanspaces.com

# Find cached/old versions of pages
cache:TARGET.com/admin

# Find subdomains not in DNS — Google has indexed them
site:*.TARGET.com -site:www.TARGET.com

[!info]+ Command Breakdown

  1. storage.googleapis.com and digitaloceanspaces.com — additional cloud storage providers beyond AWS/Azure that are often forgotten
  2. cache:TARGET.com/page — Google’s cached version of a page — may show content from before a page was taken down or secured
  3. site:*.TARGET.com -site:www.TARGET.com — the - operator excludes a site; this surfaces all indexed subdomains except www — a fast way to discover what Google has crawled

[!tip]+ Google Dork Pro Tips

  1. Use “quotes” around exact phrases — "internal use only" finds documents accidentally published
  2. Combine multiple operators: site:TARGET.com filetype:pdf intitle:"confidential"
  3. Use the - operator to subtract noise: site:TARGET.com -site:blog.TARGET.com
  4. Google limits dork results — if you hit ~30 results, rephrase or use different operators for fresh results
  5. Never use Google Dorks logged into your Google account during an engagement — your search history is tied to your identity

GrayHatWarfare — Cloud Bucket Enumeration

[!tip]+ Effective Search Strategy The notes say “search by company name” — here is a systematic approach:

Search terms to try (in order):
1. Full company name:        "InlaneFreight"
2. Common abbreviation:      "ILF"
3. Domain without TLD:       "inlanefreight"
4. Product/brand names:      [any product names found on the website]
5. Internal codenames:       [any codenames found in job postings or GitHub]

[!info]+ File Types to Prioritise

PriorityFile TypeWhy
Criticalid_rsa, id_ecdsa, .pem, .ppkSSH/TLS private keys — direct access
Critical.env, *.env.productionAPI keys, DB passwords, secrets
Highconfig.json, settings.py, web.configHardcoded credentials, internal IPs
High*.sql, *.db, *.sqliteDatabase dumps — credentials + data
Medium*.xlsx, *.csvMay contain employee lists, IP lists, passwords
Medium*.pdfInternal documentation, network diagrams
Low*.logMay contain tokens, paths, usernames in entries

[!warning]+ GrayHatWarfare Limitations

  1. Only indexes publicly accessible buckets — password-protected or private buckets won’t appear
  2. Its index is not real-time — newly exposed buckets may take days to appear
  3. Files listed may have since been removed — always verify before reporting
  4. Do NOT download files without explicit written scope permission — accessing unauthenticated cloud storage may still carry legal risk depending on jurisdiction

domain.glass — Quick Infrastructure Snapshot

[!tip]+ What to Actually Look At The notes mention it exists. Here is what to focus on when you open it:

URL: https://domain.glass/TARGET.com

[!info]+ Sections That Matter

SectionWhat to Extract
IP InformationHosting provider, ASN, IP range — tells you who hosts the infrastructure
SSL CertificateIssuer (Cloudflare? Let’s Encrypt? Internal CA?) and listed SANs (extra subdomains)
Cloudflare Status“Safe” = Cloudflare is proxying — real IP is hidden; direct IP scanning will hit Cloudflare, not the origin
DNS RecordsCross-reference against your dig output — domain.glass sometimes catches records dig any misses
Social Media LinksAuto-detected official accounts — cross-reference with your LinkedIn/staff OSINT

[!warning]+ Cloudflare Proxy Implication

  1. If domain.glass shows Cloudflare as “Safe” — the A record IP is a Cloudflare IP, not the origin server
  2. Active scanning against that IP hits Cloudflare’s infrastructure — not the target
  3. Find the real IP via: historical DNS records (SecurityTrails), SSL cert transparency, Shodan ssl.cert.subject.cn:TARGET.com, or email headers (MX trace)

LinkedIn — Staff and Tech Stack OSINT

[!tip]+ Search Syntax That Actually Works LinkedIn’s search is intentionally limited for free accounts. Here is how to work around it:

# Use Google to search LinkedIn profiles — more powerful than LinkedIn's own search
site:linkedin.com/in "TARGET company name" "software engineer"
site:linkedin.com/in "TARGET company name" "security engineer"
site:linkedin.com/in "TARGET company name" "devops"
site:linkedin.com/in "TARGET company name" "sysadmin"
site:linkedin.com/in "TARGET company name" "AWS" OR "Azure" OR "GCP"

[!info]+ Command Breakdown

  1. site:linkedin.com/in — restricts Google results to LinkedIn profile pages only
  2. Combine the company name with job titles to surface the most relevant staff
  3. Add technology keywords ("AWS", "Kubernetes", "Splunk") to find staff who list those skills
  4. Google’s index of LinkedIn is deeper than LinkedIn’s own search — especially useful without a Premium account

[!tip]+ What to Record from Each Profile

Profile SectionWhat to Note
Current Role + CompanyConfirms employment — verify you have the right person
Tech Stack in “About”Programming languages, cloud platforms, tools in active use
GitHub / Portfolio LinksJump to code search immediately — these are the highest-value leads
Career HistoryTechnologies used at each role — older systems may still be in use
CertificationsAWS/Azure certified = likely manages cloud; OSCP/CEH = security awareness is higher
Followed CompaniesMay indicate vendors they use or are evaluating
Activity / PostsRecent posts about specific tools = those tools are in active use RIGHT NOW

[!tip]+ Priority Targets on LinkedIn

  1. IT/Infrastructure admins — they configure the systems you’re targeting
  2. DevOps / SRE engineers — they wrote the pipelines that deploy to cloud
  3. Security engineers — their skills tell you what defences exist (SIEM? EDR? WAF?)
  4. Former employees — may have older, potentially still-valid credentials; less cautious about what they share post-employment
  5. Junior developers — more likely to have public GitHub repos with company-adjacent code

GitHub — Code and Secret Hunting

[!tip]+ GitHub Search Syntax Goes Far Beyond the Notes Most recon stops at “browse the repo”. GitHub has a powerful search API:

# Search for company name in ALL public code
org:TARGET-org-name                          # All repos under a specific GitHub org
user:firstname-lastname TARGET               # Repos by a specific employee mentioning the company

# Search for secrets by filename
filename:.env TARGET
filename:config.py password
filename:settings.py SECRET_KEY
filename:application.properties datasource

# Search for secrets by content
"TARGET.com" password
"TARGET.com" api_key
"TARGET.com" BEGIN RSA PRIVATE KEY
"TARGET.com" token

# Search for internal infrastructure hints
"TARGET.com" internal
"TARGET.com" 192.168.
"TARGET.com" 10.0.
"TARGET.com" staging
"TARGET.com" production

[!info]+ Command Breakdown

  1. org: — restricts search to all repositories under a GitHub organisation (the company may have an official org)
  2. filename: — searches ONLY in files with that specific name — highly targeted for common secret files
  3. “BEGIN RSA PRIVATE KEY” — literal string that starts every RSA private key — if this appears in a repo, it’s a critical finding
  4. Internal IP ranges (192.168., 10.0.) in public repos reveal internal network addressing
# Check commit history for deleted secrets — CLI approach
git clone https://github.com/target-org/repo-name
cd repo-name

# Search ALL commits for the word "password"
git log --all -p | grep -i "password" | head -50

# Search for a specific string across all branches and commits
git log --all --oneline | awk '{print $1}' | xargs -I{} git grep -l "SECRET_KEY" {}

[!info]+ Command Breakdown

  1. git log —all -p — shows every commit across all branches WITH the full diff (added/removed lines)
  2. grep -i “password” — case-insensitive search through all commit diffs
  3. Even if a secret was removed in a later commit, git log -p shows the line prefixed with + (added) and - (removed) — deleted secrets are still readable in the diff
  4. This is how most credential leaks persist — the file is “cleaned up” but the history is never purged

[!tip]+ Automated Secret Scanning Tools (Beyond Manual Search)

ToolCommandWhat It Does
trufflehogtrufflehog github --org=TARGET-orgScans all org repos + full history for 700+ secret patterns
gitleaksgitleaks detect --source=./repoScans local repo for secrets using regex rules
gitrobgitrob TARGET-orgMaps org members’ repos and scans for sensitive files

[!warning]+ GitHub OSINT Rules

  1. Only search public repositories — accessing private repos without authorisation is illegal
  2. Do not clone or download any repo that isn’t clearly in scope — downloading may constitute unauthorised access in some jurisdictions
  3. GitHub may rate-limit unauthenticated searches — authenticate with a throwaway account if needed, never your real account
  4. Findings from GitHub (leaked keys, hardcoded passwords) must be reported immediately in real engagements — they are often actively exploitable

References

  1. HTB Academy - Footprinting Module
  2. crt.sh - Certificate Transparency
  3. Shodan CLI Documentation
  4. Shodan Search Filters Reference
  5. dig Man Page
  6. jq Manual
  7. Google Advanced Search Operators
  8. GrayHatWarfare
  9. domain.glass
  10. TruffleHog - Secret Scanner
  11. Gitleaks
  12. HackTricks - DNS Enumeration
  13. HackTricks - External Recon Methodology
  14. MITRE ATT&CK - Search Open Technical Databases (T1596)
  15. MITRE ATT&CK - Search Open Websites/Domains (T1593)

#HTB #Footprinting #OSINT #Cheatsheet #DNS #Shodan #GoogleDorking #CertificateTransparency #GrayHatWarfare #GitHub #LinkedIn #SubdomainEnumeration #CloudStorage #PassiveRecon