Corporate OSINT Chain: Website, LDAP and SMTP Enumeration for Employee and Infrastructure Discovery

Why This Matters

Authentication infrastructure is the primary target of credential-based attacks — the dominant initial-access technique observed in enterprise intrusions over the past decade. Ransomware operators, business email compromise (BEC) groups, and nation-state actors all converge on the same objective: identify valid usernames, then obtain or guess passwords for those accounts. The website-to-LDAP-to-SMTP chain is a structured passive-to-semi-active methodology for mapping an organisation's authentication perimeter without triggering standard intrusion detection rules. Threat intelligence analysts use this methodology to understand how attackers profile targets; red-team operators use it to identify pre-phishing intelligence; defensive architects use it to understand what information is leaking from their own infrastructure.

Core Concept

The chain proceeds in three stages, each narrowing the intelligence picture from broad web presence to specific authentication endpoints and user accounts.

Stage 1 — Website login portal discovery: The target's public website often links directly to authentication portals: Outlook Web Access (OWA) (/owa, /mail, webmail.corp.com), VPN portals (Pulse Secure, GlobalProtect, Cisco AnyConnect web interfaces), and SSO pages (Okta, ADFS, Azure AD login). The presence and configuration of these portals reveals the organisation's identity platform and email provider. Google dorks accelerate discovery: site:targetcorp.com inurl:owa or site:targetcorp.com "Sign In" "Active Directory".

Stage 2 — LDAP exposure detection and enumeration: Lightweight Directory Access Protocol (LDAP) runs on TCP port 389 (plaintext) and 636 (LDAPS). An anonymous bind is a connection to an LDAP server that succeeds without supplying credentials, often leaving user account attributes readable. Shodan's filter port:389 org:"Company Name" identifies exposed LDAP services. The ldapsearch command with -x (simple authentication) and no bind DN attempts an anonymous bind: a successful response returns directory entries. User Distinguished Names (DNs) — e.g., cn=alice.smith,ou=Users,dc=corp,dc=com — are extracted from the response.

Stage 3 — SMTP user enumeration: Simple Mail Transfer Protocol (SMTP) provides several mechanisms for confirming whether a specific email address exists on a mail server. The VRFY command (if enabled) directly confirms or denies user existence. The RCPT TO technique sends a recipient address in a fake delivery attempt and interprets the response code: 250 OK indicates the address exists; 550 No such user indicates it does not. Timing-based enumeration exploits differences in server response latency between valid and invalid recipients when explicit error codes are suppressed. Discovered usernames from LDAP DNs are combined with the email format inferred from website analysis to generate test addresses for SMTP validation.

Technical Deep-Dive

# Stage 1: Discover login portals via Google dorks and direct path probing
# (Run in browser or via curl — entirely passive from server perspective)
# Dork examples:
#   site:targetcorp.com inurl:owa
#   site:targetcorp.com inurl:remote inurl:vpn
#   site:targetcorp.com "Powered by" "ADFS"

# Probe common portal paths
for path in /owa /mail /webmail /remote /vpn /adfs/ls /portal /sso; do
  code=$(curl -sk -o /dev/null -w "%{http_code}" -L "https://www.targetcorp.com${path}")
  echo "${path} => ${code}"
done

# Stage 2: Detect exposed LDAP via Shodan
shodan search --fields ip_str,port,org,product 'port:389 org:"Target Corporation"'

# Attempt anonymous LDAP bind and enumerate users
TARGET_LDAP="203.0.113.47"
# -x: simple auth, -H: URI, no -D/-w: anonymous bind
ldapsearch -x -H ldap://${TARGET_LDAP} -b "" -s base namingContexts 2>/dev/null
# If namingContexts returns a base DN (e.g., dc=corp,dc=com), proceed:
ldapsearch -x -H ldap://${TARGET_LDAP} 
  -b "dc=corp,dc=com" 
  "(objectClass=person)" 
  cn mail sAMAccountName userPrincipalName 2>/dev/null 
  | grep -E "^(cn|mail|sAM|userPrincipal):" | head -40

# Stage 3: SMTP user enumeration
TARGET_SMTP="mail.targetcorp.com"

# VRFY technique (if server responds to VRFY)
(echo "EHLO recon.local"; sleep 1; echo "VRFY alice.smith"; sleep 1; echo "QUIT") 
  | nc -w 5 ${TARGET_SMTP} 25

# RCPT TO technique
(
  echo "EHLO recon.local"
  sleep 1
  echo "MAIL FROM:<[email protected]>"
  sleep 1
  echo "RCPT TO:<[email protected]>"
  sleep 1
  echo "RCPT TO:<[email protected]>"
  sleep 1
  echo "QUIT"
) | nc -w 8 ${TARGET_SMTP} 25

# Sample LDAP response (anonymous bind succeeded):
# dn: cn=Alice Smith,ou=Users,dc=corp,dc=com
# cn: Alice Smith
# mail: [email protected]
# sAMAccountName: asmith
# userPrincipalName: [email protected]
#
# Sample SMTP RCPT TO response:
# 250 2.1.5 [email protected] ... Recipient OK       <- EXISTS
# 550 5.1.1 [email protected] ... User unknown     <- DOES NOT EXIST

Intelligence Collection Methodology

1. Begin with the organisation's primary website. Use Google dorks (site:, inurl:, intitle:) to discover login portals and authentication pages indexed by search engines. Record portal URLs, login page titles, and any technology identifiers (ADFS version strings, Outlook branding, Okta tenant IDs).
2. Check Shodan for the mail server IP: hostname:mail.targetcorp.com or ssl.cert.subject.cn:mail.targetcorp.com. Note the SMTP banner for software version and any ESMTP extensions listed in the EHLO response.
3. Query Shodan for exposed LDAP: port:389 org:"Target Corporation" and port:389 hostname:targetcorp.com. For any returned IPs, attempt an anonymous bind with ldapsearch -x -H ldap://IP -b "" -s base namingContexts.
4. If the anonymous bind succeeds and returns a base DN, enumerate user objects: query (objectClass=person) or (objectClass=user) with attributes cn, mail, sAMAccountName, memberOf. Export all results to a structured file.
5. Build a target email list by combining: (a) email addresses from the LDAP dump, (b) names from LDAP CNs formatted against the confirmed email pattern, (c) addresses from theHarvester or Hunter.io.
6. Probe SMTP with VRFY first (many servers disable it — a 502 Command not implemented response is expected). If VRFY is disabled, proceed to RCPT TO technique: issue MAIL FROM with a dummy sender, then send RCPT TO for each candidate address; 250 indicates existence.
7. If both VRFY and RCPT TO return identical codes for valid and invalid addresses, apply timing-based enumeration: measure response latency for 20 valid and 20 invalid candidates and apply a statistical threshold (mean ± 2 standard deviations).
8. Correlate confirmed valid email addresses against HaveIBeenPwned and public breach databases. Cross-reference with LinkedIn profiles to identify high-value targets (IT admins, finance, executives).

Common Intelligence Collection Errors

• Treating an LDAP non-response as confirmation that LDAP is not exposed: Port 389 may be filtered at the perimeter but exposed internally or via cloud-hosted directory services (Azure AD LDAP, JumpCloud). Always check port 636 (LDAPS) and look for LDAP references in web application error messages or JavaScript source.
• Missing LDAP exposure on non-standard ports: Some organisations run LDAP on alternative ports (3268 for Global Catalog, 3269 for GC over SSL) and rely on obscurity. Shodan searches should include port:3268 and port:3269 in addition to the standard 389/636.
• Using VRFY enumeration without understanding RFC compliance nuances: RFC 2821 allows servers to return 252 Cannot VRFY user for valid users rather than 250 — this is not a denial of existence, it is a refusal to confirm. Distinguish 252 (may exist) from 550/551 (does not exist).
• Sending RCPT TO probes without a preceding MAIL FROM: Many SMTP servers require a valid MAIL FROM before accepting RCPT TO. Sending RCPT TO out of sequence typically yields 503 Bad sequence of commands regardless of address validity.
• Conflating sAMAccountName with email prefix: Active Directory sAMAccountName (e.g., asmith) is not always identical to the email prefix (e.g., alice.smith). Validate the mapping explicitly via the mail and userPrincipalName attributes before constructing login credential guesses.
• Conducting SMTP probes at high speed triggering rate-limiting and alerting: Send no more than one RCPT TO probe per 2–3 seconds. Modern mail servers and cloud email providers (Exchange Online, Google Workspace) enforce connection-level rate limits and flag burst enumeration as abuse. Slow, single-threaded probing avoids automated blocks and reduces detection probability.

NICE Framework Alignment

Further Reading

• The Web Application Hacker's Handbook, 2nd Edition — Stuttard & Pinto, Chapter 10: Attacking Authentication (Wiley)
• Network Security Assessment, 3rd Edition — Chris McNab, Chapter 6: LDAP and Directory Services (O'Reilly Media)
• Penetration Testing — Georgia Weidman, Chapter 9: Exploitation (No Starch Press)