Overview

T1589.002 covers adversary collection of organizational email addresses during the reconnaissance phase, before any direct attack begins. Attackers harvest emails from public sources like LinkedIn, company websites, WHOIS records, and data breach repositories, or actively enumerate them by probing authentication endpoints such as Office 365 autodiscover, Azure AD's GetCredentialType API, and LDAP services. The goal is to build a target list of valid accounts that feeds directly into phishing campaigns, credential stuffing, and password spraying attacks.

Because this activity often happens entirely outside your perimeter — against public APIs or third-party data sources — it is easy to overlook until the attacker converts that list into an intrusion attempt. Detecting the active enumeration methods (API probing, authentication endpoint abuse) gives your team early warning before a phishing email or spray attack lands, buying critical response time. Every organization with externally visible email infrastructure is a target.

Attacker Perspective

Attackers treat email address harvesting as low-risk, high-return groundwork that directly enables nearly every follow-on technique in their playbook.

• Office 365 / Azure AD API enumeration: Tools like o365spray and MSFConsole auxiliary/gather/office365_user_enum query the https://login.microsoftonline.com/common/GetCredentialType endpoint, which returns different responses for valid vs. invalid accounts without triggering lockout, exposing valid email addresses silently.
• OSINT harvesting via TheHarvester / Hunter.io: Attackers run theHarvester -d targetcorp.com -b linkedin,google,bing to scrape publicly indexed email addresses from search engines, social media, and certificate transparency logs in minutes.
• Active Directory / LDAP enumeration from inside or via exposed services: Once inside a foothold (or via an exposed LDAP service), PowerShell like Get-ADUser -Filter * -Properties EmailAddress | Select EmailAddress or tools like ldapsearch dump the full internal email directory, confirming which harvested addresses map to active accounts.
• Autodiscover probing: Attackers send crafted requests to https://autodiscover.targetcorp.com/autodiscover/autodiscover.xml or use ruler --domain targetcorp.com --enum to confirm valid mailboxes against Exchange and Office 365 autodiscover endpoints, validating harvested lists at scale.

This technique is attractive precisely because the most effective methods require no authentication, generate minimal noise in standard log pipelines, and are nearly indistinguishable from normal web traffic unless specifically monitored.

Detection Strategy

Required Telemetry

• Azure AD / Entra ID Sign-In Logs: Enable via Azure Portal → Azure Active Directory → Diagnostic Settings → Send to Log Analytics. Captures all authentication attempts including failed ones against GetCredentialType and autodiscover. Look for ResultType, UserPrincipalName, IPAddress, and AppDisplayName fields. Required for cloud email enumeration detection.
• Azure AD Unified Audit Log: Enable via Microsoft Purview Compliance Portal → Audit → turn on auditing. Captures user enumeration events tagged as UserLoginFailed and UserLoggedIn with ResultStatus field. Retention default is 90 days; extend to 1 year for E5 licenses.
• Office 365 / Exchange Online Message Trace Logs: Available via Microsoft 365 Defender → Explorer or via PowerShell Get-MessageTrace. Used to correlate harvested addresses with subsequent inbound phishing attempts.
• Web / Reverse Proxy / WAF Logs: Capture HTTP requests to autodiscover endpoints, OWA login pages, and public-facing mail portals. Required fields: src_ip, uri_path, http_method, http_status, user_agent, bytes_sent. Enable access logging on your Exchange, IIS, or nginx/Apache reverse proxy.
• Windows PowerShell Script Block Logging (Event ID 4104): Enable via GPO: Computer Configuration → Administrative Templates → Windows Components → Windows PowerShell → Turn on PowerShell Script Block Logging = Enabled, or set registry key HKLM\SOFTWARE\Policies\Microsoft\Windows\PowerShell\ScriptBlockLogging → EnableScriptBlockLogging = 1. Captures full script text for Get-ADUser, Get-ADComputer, and LDAP filter abuse. Generates Event ID 4104 in the Microsoft-Windows-PowerShell/Operational log.
• Windows Security Event Log — LDAP / Kerberos: Enable "Audit Directory Service Access" via auditpol /set /subcategory:"Directory Service Access" /success:enable /failure:enable. Generates Event ID 4662 for object access and Event ID 5136 for attribute modification. Captures LDAP queries against AD user and computer objects.
• DNS Query Logs: Enable on your internal DNS servers (Windows DNS debug logging or RPZ logging). Captures lookups for autodiscover.* and external OSINT infrastructure from internal hosts. On Windows DNS: enable via DNS Manager → Server Properties → Debug Logging.
• Network Flow / NDR Data (e.g., Zeek, Darktrace, ExtraHop): Capture connections to TCP/443 against known OSINT and enumeration service IPs (Hunter.io, Phonebook.cz, haveibeenpwned.com). Required fields: src_ip, dst_ip, dst_port, conn_bytes, duration.

Key Indicators

• Azure AD Sign-In Logs — High-volume authentication failures from single IP: Field ResultType = 50034 (user does not exist) or 50053 (account locked) combined with IPAddress showing more than 20 unique UserPrincipalName values in under 10 minutes. This is the core signal for GetCredentialType enumeration.
• Azure AD Sign-In Logs — Enumeration-specific error codes: ResultType values 50034, 50055, 50056, 50057, 50058, 50059 returned repeatedly from the same IPAddress indicate systematic probing rather than organic login failures.
• Web/WAF Logs — Autodiscover endpoint scraping: uri_path containing /autodiscover/autodiscover.xml, /autodiscover/autodiscover.json, or /mapi/ from a single src_ip with more than 15 requests in 5 minutes. Legitimate autodiscover traffic is client-initiated and low-volume.
• Web/WAF Logs — Suspicious User-Agent strings: user_agent matching patterns like python-requests, curl/, Go-http-client, ruler, or empty user-agent strings against OWA or autodiscover paths. Tool-generated traffic rarely mimics browser agents correctly.
• PowerShell Script Block Log (Event ID 4104) — AD user email harvesting: ScriptBlockText containing Get-ADUser AND EmailAddress OR mail as a property parameter, especially combined with -Filter * (bulk dump). Example: Get-ADUser -Filter * -Properties EmailAddress.
• PowerShell Script Block Log (Event ID 4104) — LDAP filter enumeration: ScriptBlockText containing LDAP filters such as (userAccountControl:1.2.840.113556.1.4.803:=524288) or property queries for TrustedForDelegation, as flagged in the community Sigma rule. These indicate AD reconnaissance that pairs with email harvesting.
• Security Event Log (Event ID 4662) — Large-scale AD object reads: A single SubjectUserName (non-service account) generating more than 200 Event ID 4662 entries against ObjectClass = user within a 5-minute window indicates bulk directory enumeration.
• DNS Logs — Outbound lookups to known OSINT services: Internal hosts querying hunter.io, phonebook.cz, intelx.io, haveibeenpwned.com, or dehashed.com from non-security-team workstations. Use your threat intel feed to expand this list.

Detection Logic

Rule 1 (Broad — High Sensitivity): Azure AD User Enumeration via Authentication Endpoint
IF azure_signin.ResultType IN [50034, 50055, 50056, 50057, 50058, 50059] AND COUNT(DISTINCT azure_signin.UserPrincipalName) BY azure_signin.IPAddress WITHIN 10 MINUTES > 15 THEN alert("User Enumeration — Azure AD GetCredentialType Probe")

This catches automated enumeration tools like o365spray firing many invalid username probes from a single source IP. Expected volume: 1–5 alerts per week in most environments; can be noisy during credential stuffing waves. Tune threshold based on your baseline failed login volume.

Rule 2 (Medium — Balanced): Autodiscover Endpoint Scraping from Single Source
IF web_proxy.uri_path MATCHES "(?i)/autodiscover/" AND web_proxy.http_method IN ["GET","POST"] AND COUNT(web_proxy.uri_path) BY web_proxy.src_ip WITHIN 5 MINUTES > 15 AND NOT web_proxy.src_ip IN [known_mail_clients_ip_range] THEN alert("Autodiscover Endpoint Abuse — Possible Email Enumeration")

Targets tools like ruler and custom scripts probing Exchange autodiscover to validate email lists. Low to medium volume; legitimate autodiscover traffic from a single IP is almost never this frequent unless it's a mail migration tool — those should be whitelisted by IP.

Rule 3 (Precise — High Confidence): PowerShell Bulk AD Email Dump
IF event_id = 4104 AND ScriptBlockText CONTAINS "Get-ADUser" AND ScriptBlockText CONTAINS ("EmailAddress" OR "mail") AND ScriptBlockText CONTAINS ("-Filter *" OR "-LDAPFilter") AND NOT SubjectUserName IN [approved_ad_admin_accounts] THEN alert("Suspicious AD Email Harvest via PowerShell")

Directly targets bulk email address extraction from Active Directory. This is high-confidence and low-volume; legitimate helpdesk or HR pulls of email lists almost never use -Filter * against all users. Expected alert volume: fewer than 1 per week; investigate every hit.

Rule 4 (Narrow — Behavioral Correlation): Enumeration Followed by Phishing Within 48 Hours
IF azure_signin.IPAddress triggered Rule 1 WITHIN LAST 48 HOURS AND inbound_email.sender_domain NOT IN [known_good_domains] AND inbound_email.recipient IN [UserPrincipalName values probed in Rule 1] THEN alert("Probable Targeted Phishing Following Email Enumeration")

This correlation rule links a reconnaissance event to its likely follow-on action, catching campaigns where the attacker validates addresses and immediately begins phishing the confirmed accounts. Requires your SIEM to join Azure AD sign-in data with mail gateway logs. Volume will be very low; treat every hit as high priority.

Tuning Guidance

• Email migration and third-party mail tools: Tools like Microsoft ADMT, Mimecast directory sync, Proofpoint Email Protection, and hybrid Exchange connectors legitimately probe autodiscover and enumerate AD users. Exclude by src_ip IN [migration_tool_ip_range] or user_agent CONTAINS "Microsoft Office" combined with known good IP ranges.
• IT administrator AD queries: Legitimate AD admins running Get-ADUser reports for HR or compliance generate Event ID 4104 hits. Suppress by maintaining an allowlist: SubjectUserName IN [named_admin_accounts] sourced from your ITSM tool's administrator list, not just the Domain Admins group (which attackers may also use).
• Security scanning tools: Your own vulnerability scanners (Qualys, Nessus, Rapid7) and red team infrastructure will probe autodiscover and authentication endpoints. Exclude by src_ip IN [internal_scanner_ips] and tag these hosts in your asset inventory so the exclusion list stays current.
• Helpdesk and HR bulk user reports: Service desk staff frequently export user lists including email for onboarding or offboarding workflows. Identify the specific accounts and computers used for these tasks and build a named exclusion: SubjectUserName IN [hr_service_accounts] AND ComputerName IN [hr_workstations] rather than excluding the entire technique.
• Shared egress NAT IPs: If many users share a small pool of egress IPs (common in large enterprises or cloud proxy scenarios), per-IP thresholds for Rule 1 will produce false positives. Adjust the grouping field to also include UserAgent or switch to per-user failure rate thresholds instead of per-IP.

When the Alert Fires: Investigation Steps

1. Verify the alert is real — confirm the raw event exists in the source log. Pull the raw event directly from Azure AD Sign-In Logs, your WAF, or the PowerShell Operational log (Event ID 4104) and confirm the triggering field values match what the detection rule expected. Do not rely solely on the SIEM-parsed alert; check the original log to rule out parsing errors or indexing lag.
2. Identify the source IP, affected user accounts, and whether any are privileged. In Azure AD Sign-In Logs, extract all distinct UserPrincipalName values probed from the offending IPAddress and cross-reference against your identity provider to flag any C-suite, IT admin, or service account names in the target list. Elevated accounts in the probe list should immediately escalate the severity of the investigation.
3. Pull the full command-line and parent process chain for host-based alerts. For PowerShell Event ID 4104 alerts, retrieve the full ScriptBlockText and correlate with Event ID 4688 (process creation) or Sysmon Event ID 1 to identify what launched PowerShell — looking for suspicious parents like winword.exe, outlook.exe, or wscript.exe. Document the process tree in your case notes.
4. Geolocate the source IP and check threat intelligence reputation. Run the offending src_ip through your threat intel platform (e.g., VirusTotal, Shodan, AbuseIPDB, or your SIEM's built-in enrichment) and check whether it belongs to a VPN provider, Tor exit node, cloud hosting range (AWS/GCP/Azure), or a known malicious actor. Compare the IP's geolocation against the organization's normal user base — unexpected countries are a strong escalation signal.
5. Check for network connections and data written to disk on the host. For host-based alerts, use EDR telemetry (CrowdStrike, Defender for Endpoint, SentinelOne) to pull network connections and file write events from the same host and time window. Look for outbound connections to pastebin-style sites, cloud storage, or attacker infrastructure immediately following the AD query, which would indicate data exfiltration of the harvested address list.
6. Search for lateral movement or follow-on attacks originating from the identified source. In Azure AD logs, search for any successful authentications from the same IPAddress after the enumeration event — a successful login following many failures is a critical escalation indicator. For internal host-based alerts, check Sysmon Event ID 3 (network connection) and Windows Security Event ID 4624 (logon) for lateral movement to other systems using the same user account.
7. Determine whether a phishing or spray campaign followed the enumeration. Query your mail gateway logs (Proofpoint, Mimecast, Defender for Office 365) for inbound mail targeting the same email addresses identified in the enumeration probe, within a 72-hour window after the alert timestamp. If phishing or spray traffic is confirmed targeting enumerated addresses, escalate immediately to Incident Response and move to containment — this is no longer a reconnaissance-only event.

Response Playbook

Containment

• Block the offending source IP at the perimeter immediately. Add the enumeration source IP to your firewall deny list and WAF block rule, targeting all inbound traffic, not just the specific endpoint that was probed. If the IP belongs to a cloud hosting range (e.g., AWS us-east-1 CIDR), consider blocking the specific /32 while monitoring the broader range for re-emergence from adjacent IPs.
• Enable Azure AD conditional access or Named Location block for the IP range. In Azure AD → Security → Conditional Access, create a policy blocking sign-in from the identified IP or region if the geolocation is unexpected for your user base. This prevents a credential spray from succeeding even if the attacker already has a valid username list.
• If a host-based alert (PowerShell enumeration), isolate the endpoint from the network immediately. Use your EDR console (CrowdStrike → Contain Host, Defender for Endpoint → Isolate Device) to cut the host's network access while leaving it powered on for forensic memory capture. Do not reimage before forensics are complete.
• Disable or force MFA step-up for accounts confirmed in the enumerated list. If you can identify which accounts were probed (from Azure AD logs), use Azure AD → Users to temporarily require MFA re-registration or block sign-in for high-value accounts in that list while the investigation is active. Prioritize privileged and executive accounts.
• Revoke active sessions and tokens for any accounts that successfully authenticated from the suspicious IP. In Azure AD → Users → [account] → Revoke Sessions, immediately revoke all active refresh tokens. Follow up with a forced sign-out via Revoke-AzureADUserAllRefreshToken in PowerShell for any account that may have been compromised.

Eradication

• Search for any persistence mechanisms if the enumeration was host-based. On the isolated endpoint, use EDR or Autoruns (Sysinternals) to check scheduled tasks, registry run keys (HKCU\Software\Microsoft\Windows\CurrentVersion\Run), new services, and startup folders for attacker-installed persistence. Delete any identified entries and document them as IOCs.
• Identify and remove any tools or scripts dropped to disk. Search the host for PowerShell scripts, executables, or encoded payloads written during or after the enumeration event using EDR file telemetry filtered to the alert timeframe. Hash any suspicious files and submit to your threat intel platform before deleting.
• Reset credentials for any account that executed the malicious PowerShell or authenticated from the suspicious IP. Force a password reset in Active Directory and Azure AD, and invalidate all Kerberos tickets for the account using klist purge on the host. If the account has API keys or app registrations, rotate those separately.
• Audit and tighten autodiscover and OWA exposure. Review whether your autodiscover endpoint needs to be publicly accessible without any rate limiting or authentication pre-check. Implement rate limiting (e.g., 10 requests per minute per IP) on your WAF for /autodiscover/ paths, and consider requiring client certificate authentication for autodiscover if your environment supports it.
• Check for additional backdoors on any systems accessed after the enumeration. If lateral movement was detected in Step 6 of the investigation, repeat the persistence check on every destination host using your EDR's fleet query capability (CrowdStrike RTR, Defender for Endpoint Live Response, or Elastic Osquery). Assume all touched hosts are compromised until proven otherwise.

Recovery

• Verify the host is clean before reconnecting to the network — re-image if confidence is low. Use your EDR's threat score and a manual review of Autoruns, scheduled tasks, and network connections to confirm no persistence remains. If any doubt exists, re-image from a known-good baseline image rather than attempting manual cleanup; analyst time is not worth the risk of a missed backdoor.
• Re-enable blocked user accounts only after confirming no persistence remains and credentials have been reset. Work with the account owner to verify the password reset completed, MFA is enrolled on a trusted device, and no unauthorized app registrations or delegated permissions were added to the account in Azure AD during the incident window.
• Monitor the previously affected host and user accounts for 72 hours post-remediation. Create a temporary high-sensitivity watchlist in your SIEM scoped to the affected host, user accounts, and the blocked IP's broader subnet. Alert on any authentication, process execution, or network connection involving these entities, even if it would normally be below your detection threshold.
• Notify affected users if their email addresses were confirmed in a leaked dataset or enumerated list. If OSINT sources were the vector, consider using HaveIBeenPwned's domain search API to identify which organizational emails are in known breach databases and proactively reset those accounts' passwords, prioritizing privileged users.
• Document the full attack timeline and update detection rules with new IOCs discovered. Write a formal incident report capturing the initial alert, investigation steps, confirmed scope, and every IOC (IPs, user agents, script hashes, endpoint names). Feed new IOCs into your threat intel platform, update your WAF block lists, and refine the detection thresholds in your SIEM rules based on what you learned about attacker behavior in this specific incident.