Overview

T1589.001 covers adversary collection of valid credentials — usernames, passwords, MFA codes, session tokens, and API keys — that belong to or can be leveraged against a target organization. Attackers accomplish this through phishing campaigns, scraping breach dumps and dark web markets, harvesting infostealer malware logs, or compromising third-party services that handle authentication. The end goal is always the same: obtain working credentials before attempting access so the initial intrusion looks like legitimate login activity.

Every security team needs visibility into this technique because it is the silent precursor to many high-impact intrusions. By the time attackers use stolen credentials, traditional perimeter controls have already failed. Detecting reconnaissance-phase credential gathering — or its downstream signals like impossible-travel logins and credential stuffing bursts — gives defenders a chance to intervene before the breach begins.

Attacker Perspective

Attackers treat credential collection as low-risk, high-return reconnaissance that dramatically increases their chances of undetected initial access.

• Breach dump mining: Adversaries use tools like h8mail or DeHashed API queries to correlate target domain email addresses against known breach databases, retrieving plaintext or crackable password hashes in bulk.
• Infostealer log markets: Threat actors purchase stealer logs (from RedLine, Raccoon, Vidar malware families) via Telegram channels or markets like Russian Market, receiving credential packages that include saved browser passwords, cookies, and autofill data tied to corporate SSO portals.
• Phishing for credentials: Adversaries deploy adversary-in-the-middle (AiTM) phishing kits such as Evilginx2 or Modlishka that proxy legitimate login pages, capturing both passwords and session cookies to bypass MFA.
• Code repository scraping: Automated tools like truffleHog or Gitrob scan public GitHub repositories and commit histories for hardcoded API keys, service account passwords, and OAuth tokens belonging to the target organization.

This technique is attractive precisely because it happens entirely outside the defender's environment, produces no endpoint telemetry, and converts a noisy brute-force problem into a quiet single-attempt valid login.

Detection Strategy

Required Telemetry

• Azure AD / Entra ID Sign-In Logs: Enable via Azure Portal → Diagnostic Settings → send SignInLogs and NonInteractiveUserSignInLogs to your SIEM. These are the primary source for detecting credential stuffing, impossible travel, and token replay.
• Azure AD / Entra ID Risky Sign-Ins: Enable Microsoft Entra ID Protection and stream RiskyUsers and RiskDetections tables. These surface Microsoft's own credential-compromise signals including leaked credential detections from the Microsoft threat intelligence feed.
• Office 365 / M365 Unified Audit Log: Enable via Set-AdminAuditLogConfig -UnifiedAuditLogIngestionEnabled $true in Exchange Online PowerShell. Captures mailbox access, OAuth consent grants, and mail forwarding rule creation — all downstream indicators of compromised credentials.
• Identity Provider (IdP) Logs — Okta, Ping, ADFS: For Okta, enable System Log streaming via the Okta API (/api/v1/logs) or native SIEM integration. Key event types: user.authentication.auth_via_mfa, user.session.start, policy.evaluate_sign_on. For ADFS, enable audit logging via Set-AdfsProperties -LogLevel Verbose, generating Windows Event IDs 1200, 1201, 1202, 1203, 4624.
• Windows Security Event Log — Domain Controllers: Enable the following audit policies via GPO (Computer Configuration → Windows Settings → Security Settings → Advanced Audit Policy):
  • Logon/Logoff → Audit Logon: Success and Failure → generates Event ID 4624 (successful logon), 4625 (failed logon), 4648 (explicit credential use)
  • Account Logon → Audit Credential Validation: Success and Failure → generates Event ID 4776 (NTLM credential validation)
  • Account Logon → Audit Kerberos Authentication Service: Success and Failure → generates Event ID 4768 (TGT request), 4771 (pre-auth failure)
  • Account Management → Audit User Account Management → generates Event ID 4723, 4724 (password reset)
• DNS Query Logs: Enable DNS debug logging on Windows DNS servers or deploy DNS firewall logging. Captures queries to known credential-harvesting infrastructure, phishing domains, and AiTM proxy domains. In Sysmon, Event ID 22 captures DNS queries from endpoints.
• Proxy / Web Gateway Logs: Ensure your web proxy (Zscaler, Bluecoat, Squid) logs full URLs including query strings. Look for outbound requests to credential validation endpoints or known phishing page URLs.
• Email Gateway Logs: Enable logging from your SEG (Proofpoint, Mimecast, Defender for Office 365). Capture disposition, sender domain, URLs, and attachment hashes for all inbound mail — critical for detecting phishing-for-credentials campaigns.
• Sysmon (Windows Endpoints): Deploy Sysmon with a mature configuration (SwiftOnSecurity or Olaf Hartong's modular config). Key Event IDs: 1 (process create with full command line), 3 (network connection), 11 (file create), 22 (DNS query). Enable via GPO deploying sysmon.exe -accepteula -i sysmonconfig.xml.

Key Indicators

• Credential stuffing bursts — IdP/Azure AD: In SignInLogs, look for ResultType = 50126 (invalid credentials) or 50053 (account locked) with high frequency against multiple UserPrincipalName values from a single IPAddress within a short time window. A single source IP producing more than 10 failed logins across 5+ distinct accounts in 5 minutes is a strong signal.
• Impossible travel / anomalous geolocation — Azure AD: In SignInLogs, correlate Location.CountryOrRegion and CreatedDateTime across sequential authentications for the same UserPrincipalName. A login from the US followed by a login from Eastern Europe within 30 minutes is physically impossible and should trigger regardless of MFA status.
• Token replay / session cookie theft — Azure AD: In NonInteractiveUserSignInLogs, look for AuthenticationRequirement = singleFactorAuthentication combined with TokenIssuedAt timestamps that don't align with the user's known working hours, or IPAddress values differing from the interactive sign-in that issued the token.
• Leaked credential alert — Entra ID Protection: In the RiskDetections table, filter for RiskEventType = leakedCredentials. This indicates Microsoft has found the user's credentials in a known breach corpus. Treat these as confirmed compromise until proven otherwise.
• AiTM phishing kit infrastructure — DNS/Proxy: Proxy logs showing user browsers requesting URLs matching patterns like /api/auth/callback, /oauth2/authorize, or /login?token= on domains registered within the last 30 days. Cross-reference against threat intel feeds for known Evilginx2 or Modlishka C2 domains. Sysmon Event ID 22 with QueryName matching lookalike domains (e.g., login-microsoft365[.]com) is a strong endpoint signal.
• Credential scraping tools — Process telemetry: Sysmon Event ID 1 with Image or OriginalFileName matching trufflehog.exe, gitrob, h8mail, or dehashed. Command-line patterns like --regex, --entropy flags used with git repository paths are indicative of secret scanning tooling running inside the environment.
• Mass failed authentication — Windows DC: Event ID 4625 with LogonType = 3 (network logon) and SubStatus = 0xC000006A (wrong password) or 0xC0000064 (unknown username) firing rapidly across multiple TargetUserName values from a single IpAddress.
• Suspicious OAuth consent grant — M365 UAL: In the Unified Audit Log, Operation = Add app role assignment to service principal or Consent to application with a third-party ApplicationId not in your approved app inventory. Attackers use OAuth phishing to silently grant persistent access to mailboxes post-credential compromise.

Detection Logic

Rule 1: Credential Stuffing — High-Volume Authentication Failures Across Multiple Accounts
IF log_source = "AzureAD_SignInLogs" AND ResultType IN ("50126", "50053", "50055") AND time_window = 5_minutes GROUP BY IPAddress HAVING COUNT(DISTINCT UserPrincipalName) >= 5 THEN alert HIGH

This catches automated credential stuffing where an adversary cycles a password list across many accounts. Expected volume is low in most environments (0–2 alerts/day); tune the threshold based on your user population size. This will fire on legitimate password sprays from red teams or misconfigured applications — see tuning guidance below.

Rule 2: Impossible Travel — Rapid Sequential Logins from Geographically Disparate IPs
IF log_source = "AzureAD_SignInLogs" AND ResultType = "0" AND FOR same UserPrincipalName: ABS(TIMEDIFF(event1.CreatedDateTime, event2.CreatedDateTime)) < 60_minutes AND event1.Location.CountryOrRegion != event2.Location.CountryOrRegion AND GeoDistance(event1.IPAddress, event2.IPAddress) > 500_km THEN alert CRITICAL

Catches credential use from stolen credentials or purchased stealer logs where the attacker is in a different country from the legitimate user. Low false positive rate for most organizations; primary false positives are VPN exit nodes and users who travel frequently — handle via the tuning guidance below.

Rule 3: Entra ID Protection Leaked Credential Detection
IF log_source = "AADRiskDetections" AND RiskEventType = "leakedCredentials" AND RiskLevel IN ("medium", "high") THEN alert CRITICAL

Surfaces Microsoft's own threat intelligence matching your users' credentials in external breach corpora. Near-zero false positive rate; every hit should be treated as a confirmed credential exposure requiring immediate password reset and session revocation. Alert volume depends on your credential hygiene posture — organizations without regular password rotation may see dozens on first enablement.

Rule 4: AiTM Phishing Infrastructure — Lookalike Domain Access from Corporate Endpoints
IF log_source IN ("Sysmon_DNS", "ProxyLogs") AND (QueryName MATCHES regex "[a-z0-9]{3,}-?(microsoft|office365|okta|azure|sharepoint|onedrive)[a-z0-9-]*\.(com|net|org|io)" AND QueryName NOT IN allowlist_corporate_domains) AND initiating_process_name IN ("chrome.exe", "msedge.exe", "firefox.exe", "outlook.exe") THEN alert HIGH

Catches endpoint-side resolution of phishing domains mimicking corporate SSO infrastructure, characteristic of AiTM phishing kit delivery. Moderate false positive rate due to legitimate vendor subdomains — requires allowlist maintenance. Combine with email gateway alerts for highest fidelity.

Tuning Guidance

• Corporate VPN and split-tunnel configurations: VPN gateway IP ranges will trigger impossible-travel rules when users connect from home through a central egress. Exclude IPAddress IN [corporate_vpn_egress_ranges] from the source IP side of the geolocation comparison, or suppress alerts where both IPs belong to known corporate infrastructure.
• Frequent business travelers: Executives and sales staff may legitimately authenticate from multiple countries within hours. Build a known_traveler exception group and suppress impossible-travel alerts for UserPrincipalName IN [known_traveler_group] when the destination country matches their submitted travel calendar, if integrated.
• Service accounts and automated pipelines: CI/CD systems, monitoring agents, and integration service accounts generate high volumes of authentication events. Maintain an inventory and exclude UserPrincipalName IN [service_account_list] from credential stuffing volume rules — but never from failed authentication alerting entirely, as service account credential stuffing is a real attack path.
• Helpdesk password resets and account unlocks: Bulk password resets during onboarding events or after policy changes will generate Event ID 4723/4724 spikes. Exclude events where SubjectUserName matches your helpdesk service account names, and correlate against your ITSM ticket system to confirm authorized resets.
• Legitimate developer tooling (truffleHog / secret scanning): Many organizations run secret scanning tools in their own CI/CD pipelines or developer workstations as part of AppSec programs. Exclude initiating_process_parent_name = "jenkins.exe" or build-server hostnames from the credential-scraping tool detection rule, and maintain an approved tooling allowlist.
• Cloud provider and Microsoft first-party applications: Azure services, Intune, and Microsoft 365 connectors generate non-interactive sign-ins continuously. Filter AppId IN [microsoft_first_party_app_ids] from token replay rules, referencing the published Microsoft first-party app GUID list.

When the Alert Fires: Investigation Steps

1. Verify the alert is real: Pull the raw event directly from your SIEM by querying the original log source (e.g., Azure AD SignInLogs or Windows Security Event Log) using the exact timestamp and correlation ID from the alert. Confirm the fields match what the rule triggered on — rule logic bugs occasionally produce false alerts from parsing errors.
2. Identify the affected user and assess privilege level: Look up the UserPrincipalName or TargetUserName in your identity directory (Azure AD, Active Directory) and confirm whether the account holds admin roles, service account privileges, or access to sensitive systems. Privileged accounts automatically escalate the severity and compress your response timeline.
3. Pull the full authentication history for the account: In Azure AD SignInLogs or your IdP, retrieve all sign-in events for the affected user over the past 30 days, filtering for both successful (ResultType = 0) and failed events. Look for patterns — unusual hours, new device IDs, new IP addresses, or authentication from countries the user has never logged in from before.
4. Check for downstream mailbox and data access: Query the M365 Unified Audit Log for the affected account, filtering for Operations including MailItemsAccessed, FileDownloaded, FileSyncDownloadedFull, and SearchQueryInitiatedExchange. Mass email access or bulk file downloads following a suspicious login confirm credential use for data collection.
5. Investigate for OAuth application consent and mail forwarding rules: In the M365 UAL, query for Operation = "New-InboxRule" or Set-InboxRule" tied to the affected account, and check for Consent to application events with unrecognized ApplicationId values. Attackers frequently establish persistence via hidden forwarding rules or OAuth grants immediately after credential use.
6. Search for lateral movement from the affected identity: Using the confirmed attacker IP addresses from step 3, pivot to other sign-in events across all users from those same IPs in the same time window — query SignInLogs WHERE IPAddress IN [attacker_ips] AND UserPrincipalName != affected_user. On-premises, check for Event ID 4624 with LogonType = 3 originating from the affected user's endpoint to other internal hosts.
7. Make the escalation decision: Confirm incident if you find any of: successful authentication from an impossible-travel IP, mailbox access or file downloads following a suspicious login, new OAuth grants or forwarding rules, or lateral movement to additional accounts. Downgrade to false positive only if all authentications correlate to known corporate IP ranges and no downstream data access is present — document your reasoning in the ticket either way.

Response Playbook

Containment

• Revoke all active sessions and tokens immediately: In Azure AD / Entra ID, use Revoke-AzureADUserAllRefreshToken -ObjectId [UserObjectId] via PowerShell or select "Revoke sessions" in the Entra admin portal. For Okta, use the Admin Console → User → More Actions → "Clear User Sessions." This invalidates stolen session cookies and forces reauthentication across all active sign-ins.
• Disable the compromised account temporarily: In Active Directory, run Disable-ADAccount -Identity [username]. In Azure AD, set AccountEnabled = false via the portal or Graph API. Do not delete the account — preserve audit trail and mailbox data for forensics.
• Block identified attacker IP addresses at the perimeter: Submit confirmed attacker IPs to your firewall, web proxy, and conditional access policies. In Entra ID, use Named Locations in Conditional Access to block or require step-up MFA from flagged IP ranges. Document the block with the incident ticket number.
• Block identified phishing or C2 domains: Submit confirmed malicious domains to your DNS sinkhole, web proxy category override, and email gateway blocklist. For Defender for Office 365, add to the tenant block list via the Security portal under Tenant Allow/Block Lists.
• Isolate the endpoint if infostealer malware is suspected: If process telemetry (Sysmon Event ID 1) or EDR alerts suggest an infostealer was executed on a corporate device, isolate the host at the network switch or via your EDR's remote isolation feature. Keep the machine powered on to preserve volatile memory for forensic imaging.

Eradication

• Force a full password reset for the affected account: Require the user to set a new password through an out-of-band verified channel (IT helpdesk call, not email, since the mailbox may be compromised). Confirm the new password is not similar to the breached one and meets your complexity policy.
• Re-enroll MFA devices: If session cookies or OTP codes were compromised, revoke and re-enroll all MFA methods for the account. In Okta or Entra ID, delete all registered authenticators and require fresh enrollment. Consider temporarily requiring phishing-resistant MFA (FIDO2/passkeys) for the account.
• Remove malicious inbox rules and OAuth grants: In Exchange Online PowerShell, run Get-InboxRule -Mailbox [user] | Where-Object {$_.ForwardTo -ne $null -or $_.DeleteMessage -eq $true} and remove any rules not created by the user. In Entra ID, review and revoke any OAuth application consents granted during the suspicious period under the user's App Registrations.
• Hunt for and remove infostealer malware if present: On the isolated endpoint, use your EDR to scan for known infostealer artifacts. Common persistence paths for RedLine/Raccoon: %APPDATA%\Microsoft\Windows\Start Menu\Programs\Startup\, HKCU\Software\Microsoft\Windows\CurrentVersion\Run. Remove identified files and registry keys, or re-image if confidence in full removal is low.
• Rotate all secrets the compromised account had access to: Audit the account's permissions and rotate any shared credentials, API keys, service account passwords, or secrets stored in password managers or code repositories the user could access. If secrets were found in a public repository, treat them as fully compromised regardless of when they were committed.
• Search for additional compromised accounts: Using attacker IP addresses and user-agent strings from the investigation, pivot across all authentication logs to identify any other accounts successfully accessed. Repeat eradication steps for each confirmed victim account.

Recovery

• Re-image the endpoint before reconnecting if malware was confirmed: If an infostealer or credential harvester was confirmed on the device, rebuild from a known-good image rather than attempting remediation in place. Reconnect to the network only after confirming the new build passes your EDR baseline scan.
• Re-enable the user account only after full credential remediation: Confirm the password reset is complete, MFA is re-enrolled, malicious persistence is removed, and OAuth grants are cleaned up before re-enabling the account in AD or Entra ID. Communicate clearly with the user about what happened and what they should watch for.
• Apply targeted Conditional Access hardening for the affected account: For 30 days post-recovery, require the affected user to authenticate with phishing-resistant MFA (FIDO2) and restrict sign-ins to compliant, managed devices only. Use Entra ID Conditional Access or equivalent IdP policy to enforce this automatically.
• Monitor the account and host intensively for 72 hours: Create a temporary watchlist or SIEM alert for any authentication events, file access, or network connections involving the recovered account or host. If your SIEM supports it, tag the entity and increase alerting sensitivity for the watchlist period.
• Document the full attack timeline and update detections: Write a complete incident timeline from first credential exposure to containment, identifying any detection gaps. Update your SIEM detection rules with any new IOCs (IP ranges, domain patterns, user-agent strings) discovered during investigation. File a lessons-learned ticket and schedule a brief post-incident review with the SOC team within one week.