Most identity attacks start with a list: names, email addresses, valid usernames, MFA methods and already-stolen passwords, collected before the first login attempt. MITRE ATT&CK T1589 Gather Victim Identity Information (tactic Reconnaissance) covers building that list, with three v20 sub-techniques: Credentials, Email Addresses and Employee Names. Much of it happens outside your network, so the defensive work is reducing what can be learned, catching the active probing that does touch your identity provider, and acting on exposed credentials before they are used. This guide covers the technique as ATT&CK defines it, the signals in identity provider logs, the non-human credential angle and the controls that make the gathered data worthless. It is for identity engineers, detection engineers and threat intelligence analysts. For a wider external footprint programme, see the OSINT and Reconnaissance Guide; this page stays on identity data.
Key takeaways
- T1589 feeds initial access directly. ATT&CK links it forward to T1598 Phishing for Information, T1586 Compromise Accounts, T1566 Phishing, T1110 Brute Force and T1078 Valid Accounts.
- Two of three sub-techniques are barely detectable. MITRE's own detection strategies for Credentials and Employee Names say the activity often happens outside the target's visibility; focus on the next stage.
- Username and MFA enumeration does hit you. ATT&CK describes probing authentication services, including Office 365 endpoints such as autodiscover and GetCredentialType, to confirm valid accounts and permitted MFA methods.
- Exposed credentials are the highest-value find. Infostealer logs, breach dumps and code repositories hand over working passwords, tokens and API keys, many of them non-human.
- Make the list useless. Phishing-resistant MFA, no single-factor accounts, no long-lived static secrets and fast reset on exposure turn gathered identity data into dead ends.
How the technique works
ATT&CK describes T1589 as adversaries gathering identity details for targeting: personal data such as employee names, email addresses and security question answers, and sensitive details such as credentials and MFA configuration. Sources include direct elicitation through phishing, active probing of authentication services (T1595 Active Scanning), and online data sets such as social media (T1593.001) and the victim's own websites (T1594). It is a PRE platform technique: it describes adversary preparation rather than activity on your hosts.
| Sub-technique (v20) | What is gathered | Typical sources ATT&CK names | MITRE detection strategy |
|---|---|---|---|
| T1589.001 Credentials | Passwords, cookies, tokens, MFA codes via a compromised provider | Phishing for information, breach dumps, code repositories, search engines, dark web markets, Telegram channels selling infostealer logs | DET0813: largely outside visibility; detect at initial access |
| T1589.002 Email Addresses | Addresses and username formats | Social media, victim websites, enumeration of authentication endpoints such as autodiscover and GetCredentialType in Office 365 | DET0814: iterative authentication requests from one source; web metadata |
| T1589.003 Employee Names | Names, roles and reporting lines used to derive addresses and craft lures | Social media, victim websites, leaked data sets | DET0857: very high false positive rate; detect later stages |
| T1589 (parent) | Any of the above plus MFA configuration | Probing authentication and self-service password reset responses | DET0841: large or iterative authentication requests from one source |
T1589 sits beside T1590 Gather Victim Network Information, T1591 Gather Victim Org Information and T1597 Search Closed Sources. ATT&CK assigns a single mitigation, M1056 Pre-compromise, which is an admission that prevention mostly means reducing exposure rather than blocking an action.
Where it shows up
- Help desk pretexting: the attackers in the MGM Resorts Breach 2023 said they found an employee on LinkedIn, then called the help desk as that person. ATT&CK links T1589 to Scattered Spider (G1015) and LAPSUS$ (G1004).
- Infostealer credentials: in the Snowflake Breach 2024, Mandiant found at least 79.7% of accounts used had prior exposure in infostealer logs, some from infections dating to November 2020, and none had MFA.
- Bought contractor passwords: Uber said the attacker likely bought a contractor's password after malware infected a personal device, then used repeated push prompts until one was accepted, as covered in the Uber Breach 2022 analysis.
- Nation-state targeting: ATT&CK v20 links T1589.002 to groups including Volt Typhoon, HAFNIUM, Kimsuky and Silent Librarian, and T1589.001 to APT28 and ShinyHunters.
- Machine credentials: ATT&CK's T1589.001 citations include leaked Slack tokens and GitHub credentials. Exposed API keys and tokens are identity information too; see the Git Secret Scanning Guide.
Detection
Detection splits into what touches your identity provider and what you learn from outside sources.
| Signal | Where to see it | What it suggests |
|---|---|---|
| Bursts of AADSTS50034 UserAccountNotFound from one source or ASN | Entra ID sign-in logs | Username enumeration against a candidate list |
| Many AADSTS50126 InvalidUserNameOrPassword across many accounts, few per account | Entra ID sign-in logs | Password spray using a gathered list (T1110.003) |
| AADSTS50053 lockouts or malicious IP blocks across accounts | Entra ID sign-in logs, failure reason field | Spray or brute force reaching thresholds |
| AADSTS50076 MFA required on attempts for many users | Entra ID sign-in logs | Correct passwords being tested; treat the passwords as exposed |
Leaked credentials risk detection (leakedCredentials) | Entra ID Protection, user risk, offline, available without P2 | Microsoft matched a found credential against your current password hashes; always high risk |
| Password spray, malicious IP and verified threat actor IP detections | Entra ID Protection, sign-in risk (P2) | Use of gathered lists from known infrastructure |
| Self-service password reset probing without completion | Identity provider audit logs for reset flows | Discovery of registered MFA methods |
| Company credentials in infostealer logs or breach dumps | Threat intelligence or dark web monitoring feeds | T1589.001 has happened; reset and revoke sessions |
| Secrets in public repositories, images or paste sites | Secret scanning on organisation and staff repositories | Non-human credentials gathered or available |
Microsoft describes the leaked credentials pipeline as monitoring dark web forums, breach dump repositories, paste sites and law enforcement seizure data, then raising a detection only on a confirmed match. Equivalent detections exist in other identity providers; check your own. For infostealer feeds and triage, see the Infostealer Logs Monitoring and Response Guide and the Dark Web Monitoring Guide.
Detections to build first
- Enumeration rate: distinct usernames with UserAccountNotFound per source IP or ASN per hour, against a baseline.
- Spray shape: one source, many accounts, one or two failures each, within a short window.
- Correct password, failed MFA: treat as a confirmed credential exposure even though login failed.
- Leaked credential alert to reset: automate a forced reset and session revocation on any high user risk from leaked credentials.
- External exposure intake: a ticket for every company credential or secret found in feeds, with an owner and a revocation deadline.
Metrics
- Time from exposure notice to reset or revocation: hours for humans, minutes for API keys and tokens.
- Single-factor accounts: count of human and service accounts that can sign in with a password alone, trending to zero.
- Phishing-resistant MFA coverage: percentage of privileged and help desk users on FIDO2 or equivalent.
- Enumeration alerts acted on: percentage leading to blocks or conditional access tightening.
- Exposed secrets still valid after 24 hours: should be zero.
Reducing what can be gathered
| Exposure | Control | Trade-off |
|---|---|---|
| Predictable email and username formats | Accept that formats leak; rely on strong authentication rather than secrecy of usernames | Changing formats is costly and rarely worth it |
| Help desk and IT staff named publicly | Limit role detail on public sites; train staff on pretexting that uses their public profile | Recruiting and marketing want visible staff |
| Authentication endpoints that reveal account existence | Uniform error responses on your own login pages; rate limits and lockout tuned to slow enumeration | Some SaaS and identity provider endpoints are outside your control |
| MFA methods discoverable through reset flows | Require strong verification before revealing methods; remove SMS and voice for privileged users | Help desk load during migration |
| Credentials on unmanaged devices | Managed devices for contractor access; token binding and short sessions | Contractor friction |
| Static secrets in code and images | Push protection, workload identity federation, short-lived tokens | Engineering effort to migrate |
Where identity fits
T1589 is identity reconnaissance, so identity controls decide whether it matters.
- Remove the single factor: Snowflake later phased out password-only sign-in for human users and for service users with programmatic access, a direct response to credentials gathered from infostealers. Apply the same rule to your platforms. See the Phishing-Resistant MFA Guide.
- Treat non-human credentials as identity data: API keys, personal access tokens and service account passwords found in code are T1589.001 finds. Prefer key pair, OAuth or workload identity federation, and give every service account an owner.
- Verify at the help desk: a caller who knows a name, role and employee number has only shown they did reconnaissance. See the Vishing and Help Desk Social Engineering Awareness Guide.
- Contractors and suppliers: their personal devices and repositories are part of your identity attack surface, as Uber showed.
Responding to identity exposure
- Confirm validity: is the credential, token or key current? Identity provider leaked credential checks and secret scanner validity checks answer this.
- Reset and revoke: reset the password, revoke refresh tokens and sessions, rotate or delete the key.
- Review use: search sign-in and audit logs for the account or key across its exposure window.
- Contain enumeration sources: block or challenge the source ranges and tighten conditional access for targeted groups.
- Warn targeted staff: enumeration of a team often precedes phishing or vishing against it.
The Leaked Credential Response Playbook covers the full process.
Common failure patterns
- Ignoring failed logins that had the right password: an MFA-required failure means the password is known.
- Leaked credential alerts with no automation: high user risk sits in a queue while the attacker uses the password.
- Single-factor service and legacy accounts: the Snowflake pattern; MFA everywhere except where the stolen credential works.
- Push MFA for privileged users: gathered passwords plus prompt bombing, as in Uber. See the MFA Fatigue and Bypass Guide.
- Monitoring only corporate repositories: staff and contractor personal repositories leak organisation secrets too.
- Treating usernames as secrets: spending effort hiding formats instead of hardening authentication.
Framework mapping
| Framework | Reference | Relevance |
|---|---|---|
| MITRE ATT&CK v20 | T1589, T1589.001, T1589.002, T1589.003; related T1590, T1591, T1593.001, T1594, T1595, T1597; next stage T1598, T1586, T1566, T1110.003, T1078, T1621 | Technique and kill chain |
| ATT&CK mitigation | M1056 Pre-compromise | Only mapped mitigation |
| NIST SP 800-53 Rev 5 | IA-2 Identification and Authentication; IA-5 Authenticator Management; AC-7 Unsuccessful Logon Attempts; SI-4 System Monitoring; PM-16 Threat Awareness Program | Control baseline |
| NIST CSF 2.0 | ID.RA-02 threat intelligence received; PR.AA-03 users and services authenticated; DE.CM-03 personnel activity monitored | Outcomes |
| CIS Controls v8.1 | 6.3 to 6.5 MFA for externally exposed applications, remote access and administrative access; 14 Security Awareness and Skills Training | Safeguards |
Practitioner checklist
- Alert on username enumeration and spray shapes in identity provider sign-in logs.
- Treat MFA-required failures with a correct password as credential exposure.
- Automate reset and session revocation on leaked credential risk detections.
- Subscribe to infostealer and breach data feeds for company domains and act on every hit.
- Scan organisation, staff and contractor repositories and images for secrets; revoke within hours.
- Eliminate single-factor sign-in for human and service accounts.
- Move privileged and help desk staff to phishing-resistant MFA.
- Brief help desk staff that knowledge of names and roles proves nothing.
Standards and references
- MITRE ATT&CK: Gather Victim Identity Information (T1589)
- MITRE ATT&CK: Credentials (T1589.001)
- MITRE ATT&CK: Email Addresses (T1589.002)
- Microsoft Learn: What are risk detections? (Microsoft Entra ID Protection)
- Microsoft Learn: Microsoft Entra authentication and authorisation error codes
- NIST: SP 800-53 Rev 5 Security and Privacy Controls
- NIST: Cybersecurity Framework 2.0
Related NHI Mgmt Group resources: OSINT and Reconnaissance Guide · Password Spraying and Credential Stuffing Defence Guide · Infostealer Threat Guide · MITRE ATT&CK T1586 Compromise Accounts Guide · MITRE ATT&CK T1598 Phishing for Information