Adversaries may gather email addresses for use during targeting. MITRE lists this under Reconnaissance with platform PRE. It was last modified in May 2026.
Even organizations with internal mail systems usually have public facing email infrastructure and employee addresses. That makes this one of the most available kinds of target data.
How attackers use it
MITRE says addresses are often readily available through online data sets, such as social media or the organization's own websites. They can also be confirmed by active means, such as probing authentication services and analyzing whether the response reveals a valid username.
As an example, MITRE says adversaries may enumerate email addresses in Office 365 environments by querying publicly available API endpoints such as autodiscover and GetCredentialType.
The result feeds later stages: more reconnaissance, setting up email accounts as operational resources, and initial access through phishing or through brute force against external remote services.
Email enumeration works because mail and identity systems need to answer some questions publicly. A mail server has to say where to deliver; a sign-in page has to say whether a login worked. If the answer differs between a real address and a fake one, the difference leaks information.
MITRE's Office 365 example shows the cloud version of the same idea. Public endpoints exist to help clients find the right service, and they can respond differently for valid and invalid accounts.
A confirmed address list has uses beyond phishing. MITRE links it to brute force attempts against external remote services. A list of real usernames turns a blind guess into a narrower one.
How to detect it
MITRE recommends monitoring for suspicious network traffic that looks like probing for email addresses or usernames, with large or repeated quantities of authentication requests from a single source as the example, especially where the source is associated with an adversary or botnet.
It also recommends analyzing web metadata, including referer and user-agent fields, for artifacts attributable to malicious activity.
Useful signals include a burst of failed sign-ins across many different usernames from one address, requests to identity discovery endpoints at unusual volume, and sign-in attempts for addresses that do not exist in your directory.
Attempts for accounts that do not exist can be a useful signal, though some will be typing mistakes.
Look for the shape of enumeration in your identity provider's logs. Legitimate failures cluster on a few users who mistype a password. Enumeration spreads across many usernames, with one or two attempts each, from one or a few addresses.
Add a count of distinct usernames tried per source address per hour. A source that tries dozens of different accounts in an hour is not a person who forgot a password.
Do not overlook web metadata, as MITRE suggests. User-agent strings that belong to scripting libraries instead of browsers, and referer fields that are empty on requests to a sign-in endpoint, are ordinary clues in this kind of traffic.
Keep a short list of what to do when an enumeration run is found: block or challenge the source, check whether any attempt succeeded, notify the owners of the targeted accounts if there is reason to, and make sure MFA covers them.
How to reduce the risk
- MITRE says preventive controls cannot easily stop this and that efforts should focus on minimizing the amount and sensitivity of data available to external parties.
- Avoid publishing individual addresses where a role address would serve, for example for contact and support.
- Limit how much of the staff directory is visible to the public and to scrapers.
- Rate limit authentication endpoints and alert on username cycling.
- Where your identity provider allows it, review settings that influence whether responses differ for valid and invalid users.
- Enforce MFA, so a guessed or leaked address alone does not lead to access.
Treat the address list as public and design for that. Strong MFA, lockout or throttling that cannot be bypassed by spreading across accounts, and alerts on distributed attempts matter more than trying to hide addresses.
For staff, prepare for mail that arrives addressed correctly. A message that uses the right address and name proves nothing about its sender. Show an external sender marker and keep a simple way to report.
Finally, test your own sign-in flow. Try a valid and an invalid username and compare the responses, including timing and message text. If they differ, raise it with the owner of the identity system.
Check your own environment
A read-only check of your public mail records, using dig on Linux or macOS:
dig +short MX yourdomain.com
dig +short TXT yourdomain.com
These records are public by design. Look at what they reveal about your providers, then ask:
- Which employee addresses appear on our website, and why?
- Do we alert on failed sign-ins for accounts that do not exist?
- Is MFA enforced for every mailbox exposed to the internet?
- Who reviews authentication logs for username cycling?
Quick check
How can an adversary confirm an email address is valid without sending mail?
By probing authentication services or related endpoints and analyzing whether responses reveal a valid username. MITRE cites Office 365 endpoints such as autodiscover and GetCredentialType as examples.
What is the best signal in logs?
Many authentication requests from one source across varying usernames, particularly for addresses that do not exist.
Sources
- MITRE ATT&CK, Email Addresses (T1589.002): https://attack.mitre.org/techniques/T1589/002
