Gathering victim identity information means collecting details about the people in an organization that help with targeting. MITRE lists it under Reconnaissance, with platform PRE. The parent technique has three sub-techniques: credentials, email addresses, and employee names.
Identity details can be personal, such as names, email addresses, and answers to security questions, or sensitive, such as credentials and multi-factor authentication configurations.
How attackers use it
MITRE describes three kinds of source. The first is direct elicitation, for example phishing for information. The second is active enumeration, where an adversary probes authentication services and reads the responses, which may reveal valid usernames or the MFA methods allowed for those users. The third is data that is already exposed, such as social media or the organization's own websites.
Collected identity data opens other doors. MITRE says it can lead to further reconnaissance, to setting up operational resources such as compromised accounts, and to initial access through phishing or valid accounts.
The thread through all of it is that identity information is cheap to collect and useful at every later stage.
The sub-techniques show how the pieces fit together. Names lead to email addresses; email addresses confirm valid usernames; usernames meet credentials; credentials meet MFA settings. Each step makes the next one cheaper.
MITRE's mention of MFA configuration is worth pausing on. Probing an authentication service can reveal which methods are allowed for a username. An attacker who learns that a user relies on a weaker method can choose a lure to match.
This also explains MITRE's guidance on exposure. You cannot stop a person from reading a public page, but you can decide which fields appear on it.
Defenders can also learn from how the information is collected. Phishing for information is a direct request to a person, so a staff member who recognizes it and reports it removes a source. Active probing of authentication is a request to a system, so a system that answers uniformly removes another. Public data is the third source, and the owner of the website and social accounts controls it.
How to detect it
MITRE suggests watching for suspicious network traffic that looks like probing for user information. The example it gives is large or repeated quantities of authentication requests from a single source, especially a source known to be associated with an adversary or botnet.
It also points at web metadata. Referer and user-agent fields in HTTP logs can reveal artifacts that are attributable to malicious activity.
In practice, look at your authentication endpoints. Many attempts against different usernames from one address, or a steady pattern of requests that differ only in the username, is the signal. Responses that differ for valid and invalid users make this probing easier, so check that yours do not.
Compare the data you collect at sign-in with what you need. Identity provider logs often include the username tried, source address, client details, and result. That is enough to build a simple report: distinct usernames per source, failures per source, and successes that follow failures.
Review that report weekly at first, then set alerts on the patterns that matter to you. Pair it with reports from staff who receive messages that use their details in unusual ways.
If you run public APIs that accept usernames or emails, such as password reset or sign-up forms, include them in the review. They can answer the question of whether an account exists just as a login page can.
How to reduce the risk
- MITRE's mitigation is candid: this cannot be easily mitigated with preventive controls because it is based on behaviors outside the scope of enterprise defenses. It adds that efforts should focus on minimizing the amount and sensitivity of data available to external parties.
- Review what your public website, job postings, and staff profiles reveal, and remove what has no business purpose.
- Make sign-in pages respond the same way for valid and invalid usernames where you control the behavior.
- Rate limit and alert on authentication attempts that cycle through many usernames.
- Assume names and email addresses are known, and make sure they alone are not enough to get in.
- Treat leaked credentials and exposed MFA settings as more sensitive than names, and prioritize them.
A final practice is to run your own exercise. Ask someone to spend an hour collecting identity information about your company from public sources only, then review what they found. Nothing beats seeing your exposure from the outside.
Use the result to prune public pages, to adjust training with real examples from your own staff and systems, and to set priorities for MFA coverage.
Assign an owner to each of the three sources: someone for people and training, someone for authentication behavior, and someone for public content. Without owners, each is assumed to be handled elsewhere.
Check your own environment
The log check below is for a web server that uses nginx with the default access log. Adjust the path for your setup.
# Linux, nginx default log: top client addresses by request count
awk '{print $1}' /var/log/nginx/access.log | sort | uniq -c | sort -rn | head -20
Then compare the busiest addresses against the sign-in URL. A short list of questions to carry with you:
- What can a stranger learn about our staff from our own public pages?
- Do our login responses reveal whether a username exists?
- Which sources send many authentication requests with changing usernames?
- Is MFA configured so that a known username alone gives little?
Quick check
Name the three sub-techniques of T1589.
Credentials, email addresses, and employee names.
What does MITRE say defenders should focus on?
Minimizing the amount and sensitivity of data available to external parties, since the collection itself cannot be easily prevented.
Sources
- MITRE ATT&CK, Gather Victim Identity Information (T1589): https://attack.mitre.org/techniques/T1589
