Corporate OSINT Chain: WHOIS, LDAP and SMTP Correlation for Organizational Intelligence

Why This Matters

A single WHOIS record is a seed capable of growing into a complete map of an organisation's authentication perimeter. Investigators — from fraud analysts tracing phishing infrastructure to red-team operators building target packages — routinely start from nothing more than a domain name and use registrant data to discover the entire portfolio of infrastructure owned by the same entity. Corporate espionage cases documented in public court records have shown that perpetrators used exactly this chain: WHOIS registrant email → all associated domains → subdomain enumeration → exposed directory services → credential harvest. Defensive teams who understand how this pivot chain works can audit their own WHOIS records for information minimisation and monitor for LDAP and SMTP exposure before attackers discover it.

Core Concept

The chain pivots on WHOIS registrant data — the name, email address, organisation, and physical address that domain registrants supply at registration time. While WHOIS privacy services mask this data for many consumer domains, corporate domains frequently carry accurate registrant data either because the privacy service was not applied consistently or because the data was accurate at registration and has since become stale.

Reverse WHOIS flips the standard lookup: instead of querying a domain to get registrant data, you query a registrant attribute to get all associated domains. Services including viewdns.info (free tier), DomainTools (commercial), and SecurityTrails maintain historical WHOIS corpora that support reverse queries. A single corporate registrant email (e.g., [email protected]) may resolve to dozens of domains registered over the company's history — including development environments, acquired subsidiary domains, and lapsed microsites.

Subdomain enumeration on each discovered domain extends the surface: even a lapsed marketing microsite may share infrastructure with the primary domain or carry subdomains pointing to internal staging servers.

LDAP service discovery uses the discovered IP ranges — inferred from DNS A records and ASN lookups on discovered domains — to identify exposed directory services. Shodan's port:389 net:CIDR filter searches the entire ASN netblock for LDAP listeners. Anonymous bind enumeration then extracts user Distinguished Names, account attributes, and group memberships from any misconfigured LDAP server.

SMTP user existence verification closes the chain: discovered usernames (from LDAP sAMAccountName and cn attributes) are formatted as email addresses using the pattern confirmed from MX analysis, then probed via VRFY or RCPT TO to confirm live accounts.

Technical Deep-Dive

# Step 1: WHOIS — extract registrant email
whois targetcorp.com | grep -iE "Registrant Email|Admin Email|Tech Email"
# => Registrant Email: [email protected]

# Step 2: Reverse WHOIS on viewdns.info (browser-based, no CLI without account)
# URL: https://viewdns.info/reversewhois/?q=domains%40targetcorp.com
# Output: list of all domains registered by that email

# Alternatively via DomainTools API (requires subscription):
curl -s "https://api.domaintools.com/v1/reverse-whois/[email protected]&mode=purchase" 
  -u "$DT_USER:$DT_KEY" | jq '.response.domains[]'

# Step 3: Enumerate subdomains for all discovered domains
while read domain; do
  echo "=== $domain ==="
  amass enum -passive -d "$domain" -timeout 10 2>/dev/null
done < discovered_domains.txt > all_subdomains.txt

# Step 4: Resolve subdomains → IPs → ASN lookup
dnsx -l all_subdomains.txt -a -resp -silent | awk '{print $2}' | sort -u > resolved_ips.txt
# ASN lookup for first IP to get CIDR
whois -h whois.cymru.com " -v $(head -1 resolved_ips.txt)" | tail -1
# => AS12345 | 203.0.113.0/24 | ... | Target Corporation

# Step 5: Shodan LDAP search across ASN netblock
shodan search --fields ip_str,port,product 'port:389 net:203.0.113.0/24'
# Also check Global Catalog:
shodan search --fields ip_str,port 'port:3268 net:203.0.113.0/24'

# Step 6: Anonymous LDAP bind — enumerate user DNs
LDAP_IP="203.0.113.47"
ldapsearch -x -H ldap://${LDAP_IP} -b "dc=corp,dc=com" 
  "(objectClass=user)" sAMAccountName cn mail memberOf 2>/dev/null 
  | grep -E "^(dn|sAMAccountName|cn|mail|memberOf):" > ldap_users.txt

# Step 7: Extract unique sAMAccountNames and build email candidates
grep "^sAMAccountName:" ldap_users.txt | awk '{print $2}' | sort -u > samaccounts.txt
# Apply format [email protected] using full CN:
grep "^cn:" ldap_users.txt | awk -F": " '{print $2}' | while read name; do
  first=$(echo "$name" | awk '{print tolower($1)}')
  last=$(echo "$name" | awk '{print tolower($2)}')
  echo "${first}.${last}@targetcorp.com"
done > email_candidates.txt

# Step 8: SMTP RCPT TO verification
while read email; do
  response=$(printf "EHLO test.local
MAIL FROM:<[email protected]>
RCPT TO:<%s>
QUIT
" 
    "$email" | nc -w 4 mail.targetcorp.com 25 2>/dev/null)
  code=$(echo "$response" | grep "^250" | grep -i "rcpt|recipient|OK" | wc -l)
  [ "$code" -gt 0 ] && echo "VALID: $email" || echo "INVALID: $email"
done < email_candidates.txt

# Sample ldap_users.txt excerpt:
# dn: cn=Bob Jones,ou=IT,dc=corp,dc=com
# cn: Bob Jones
# sAMAccountName: bjones
# mail: [email protected]
# memberOf: cn=Domain Admins,cn=Users,dc=corp,dc=com   <- HIGH VALUE TARGET

Intelligence Collection Methodology

1. Run whois on the primary target domain. Extract all contact emails (Registrant, Admin, Tech). If the record is privacy-masked, check SecurityTrails historical WHOIS for the domain — privacy masking is often applied retroactively, leaving earlier records with real data.
2. Submit each discovered registrant email to a reverse WHOIS service (viewdns.info for free spot-checks, DomainTools or SecurityTrails for comprehensive results). Record all associated domains with their registration dates.
3. Prioritise recently registered domains (last 2 years) and those with obvious corporate naming conventions. Run amass in passive mode against each domain.
4. Feed all discovered subdomains into dnsx for bulk resolution. Deduplicate IP addresses and perform ASN lookups using the CYMRU whois service to identify all CIDR blocks attributable to the organisation.
5. Search Shodan for LDAP across the identified netblocks: port:389 net:<CIDR>, port:636 net:<CIDR>, port:3268 net:<CIDR>. Attempt anonymous binds on any returned IPs.
6. From successful LDAP enumeration: extract cn, sAMAccountName, mail, userPrincipalName, and memberOf. Prioritise accounts in Domain Admins, IT, or Network Admins groups — these are the highest-value targets for an actual attacker.
7. Confirm the organisation's email format from the mail attribute in LDAP results. Apply this format to all cn entries that lack a mail attribute to generate additional candidates.
8. Probe SMTP at mail.targetcorp.com (from MX record) or any other identified mail server with the RCPT TO technique. Validate only the top-priority targets to minimise noise in server logs.
9. Document the complete chain: WHOIS seed → X domains discovered → Y subdomains enumerated → Z IPs resolved → LDAP exposed at IP:PORT → N user accounts harvested → M email addresses SMTP-confirmed.

Common Intelligence Collection Errors

• Ignoring WHOIS nameserver data: Nameservers often reveal the DNS hosting provider (e.g., NS1, Cloudflare, AWS Route 53). Multiple domains sharing the same nameserver cluster are likely owned by the same entity even if registrant data differs — a useful corroboration signal when registrant emails are inconsistent.
• Not checking historical WHOIS snapshots for expired privacy masking: Privacy protection services can expire or be removed during registrar transfers. A domain that currently shows privacy-masked WHOIS may have a 5-year-old snapshot with full registrant contact details.
• Conflating the registrant email domain with the target domain: An organisation may register domains using a third-party registrar account with a generic email ([email protected]). Reverse WHOIS on such an email returns thousands of unrelated domains. Validate that discovered domains are actually controlled by the target before investing enumeration effort.
• Enumerating LDAP without checking memberOf attributes: The organisational intelligence available in LDAP is far richer than just usernames. memberOf reveals group memberships (Domain Admins, VPN Users, Finance), description fields often contain role or asset information, and lastLogon timestamps indicate which accounts are active.
• Sending too many SMTP probes against cloud-hosted mail: Office 365 and Google Workspace implement aggressive rate-limiting and reputation scoring at the IP level. A single IP sending more than 10–15 RCPT TO probes in rapid succession may be blocked for hours or flagged for abuse review, burning the source IP for future use.
• Failing to cross-reference LDAP mail and userPrincipalName fields: These two attributes are not always identical. The mail attribute reflects the user's primary email address; userPrincipalName (UPN) is used for authentication to Azure AD/Office 365. For cloud-hybrid environments, the UPN is the correct value to use in credential validation attempts.

NICE Framework Alignment

Further Reading

• Open Source Intelligence Techniques, 9th Edition — Michael Bazzell, Chapter 11: Domain and IP Research (IntelTechniques)
• The Practice of Network Security Monitoring — Richard Bejtlich, Chapter 3: Collecting Network Evidence (No Starch Press)
• Network Security Assessment, 3rd Edition — Chris McNab, Chapter 6: LDAP and Directory Services (O'Reilly Media)