Overview

T1589 (Gather Victim Identity Information) is a pre-compromise reconnaissance technique where adversaries collect details about target individuals — employee names, email addresses, credentials, MFA configurations, and security question answers — before launching an attack. This intelligence fuels downstream operations including spear-phishing, credential stuffing, and account takeover without requiring any initial foothold on the victim's infrastructure.

Because this technique largely occurs outside your perimeter (on dark web forums, public LinkedIn scrapes, or against authentication endpoints), detection windows are narrow and easy to miss. Teams that don't monitor for enumeration signals against their identity providers, leaked credential databases, or authentication service probing will often learn about this reconnaissance only after an account has already been compromised.

Attacker Perspective

Attackers use T1589 to build a precise target list before committing any intrusion resources, dramatically improving the success rate of subsequent phishing, credential stuffing, or social engineering campaigns.

• SSH Username Enumeration (CVE-2018-15473): Attackers run python3 CVE-2018-15473.py --userList wordlist.txt --threads 20 target.example.com against exposed SSH daemons to confirm which usernames are valid, exploiting a timing difference in OpenSSH's handling of malformed public key packets.
• Azure AD / Entra ID SSPR Probing: Attackers send unauthenticated requests to the Self-Service Password Reset endpoint (https://passwordreset.microsoftonline.com) with known or guessed UPNs to confirm account existence and discover enrolled MFA methods without triggering a login failure.
• Active Directory Delegation Discovery via PowerShell: After obtaining initial access, attackers run Get-ADComputer -Filter * -Properties TrustedForDelegation | Where-Object {$_.TrustedForDelegation -eq $true} to identify systems configured for unconstrained Kerberos delegation, enabling credential harvesting at scale.
• Credential Leak Harvesting via OSINT Tools: Attackers use tools like h8mail, Holehe, or manually query breach aggregators (Have I Been Pwned API, dark web paste sites) to match corporate email domains against known leaked credential dumps, then attempt direct login or password spraying.

This technique is attractive because most of its execution happens before any malicious code touches the target environment, making it nearly invisible to endpoint-focused defenses and giving attackers high-quality intelligence at very low cost and risk.

Detection Strategy

Required Telemetry

• Azure AD / Entra ID Risk Detections: Enable Identity Protection in your Entra ID tenant (requires at minimum Azure AD P1). Risk events stream to the riskDetections and riskyUsers tables in Microsoft Sentinel (via the Entra ID connector) or can be exported via Diagnostic Settings to a Log Analytics Workspace. Ensure the connector is ingesting SignInLogs, AuditLogs, and AADRiskyUsers.
• Windows PowerShell Script Block Logging (Event ID 4104): Enable via GPO at Computer Configuration → Administrative Templates → Windows Components → Windows PowerShell → Turn on PowerShell Script Block Logging, or directly in the registry at HKLM\SOFTWARE\Policies\Microsoft\Windows\PowerShell\ScriptBlockLogging → EnableScriptBlockLogging = 1 (DWORD). This generates Event ID 4104 in the Microsoft-Windows-PowerShell/Operational log for every script block executed.
• Windows PowerShell Module Logging (Event ID 4103): Enable at HKLM\SOFTWARE\Policies\Microsoft\Windows\PowerShell\ModuleLogging → EnableModuleLogging = 1 and set ModuleNames to * to capture all module activity including ActiveDirectory module cmdlets.
• Linux SSH Authentication Logs: Ensure /var/log/auth.log (Debian/Ubuntu) or /var/log/secure (RHEL/CentOS) is being shipped to your SIEM. Configure your log shipper (Filebeat, rsyslog forwarding, or Splunk Universal Forwarder) to ingest the sshd facility. No additional audit rule is needed — sshd writes these natively.
• Azure AD Sign-In Logs: Stream SignInLogs and NonInteractiveUserSignInLogs to your SIEM. In Sentinel, this is done via the Entra ID data connector. In Splunk, use the Splunk Add-on for Microsoft Cloud Services. Look specifically for authentication attempts that fail with error codes indicating username enumeration (50053, 50126, 50055, 50056).
• Network/Perimeter Logs (for SSPR probing): Enable logging on your web application firewall or proxy for outbound and inbound requests to passwordreset.microsoftonline.com and login.microsoftonline.com. Source IP reputation enrichment (via threat intel feeds) dramatically increases signal quality here.
• Have I Been Pwned / Credential Monitoring Integration: If your organization uses a third-party credential exposure monitoring service (SpyCloud, Entra ID Protection's leaked credentials detection, or similar), ensure those alerts are being ingested into your SIEM as structured events.

Key Indicators

• Azure AD Risk Detection — Leaked Credentials: Log source: AADRiskDetections (Sentinel) or azure:aad:riskdetection (Splunk). Field: riskEventType = leakedCredentials. This fires when Microsoft's threat intelligence identifies a user's credentials in a public breach dump or dark web source.
• SSH Username Enumeration (CVE-2018-15473): Log source: Linux syslog (/var/log/auth.log). Field: message contains error: buffer_get_ret: trying to get more bytes 1907 than in buffer 308 [preauth]. Multiple occurrences from a single source IP within a short window are a strong indicator of automated enumeration tooling.
• PowerShell Delegation Discovery: Log source: Windows Event Log, Event ID 4104 (PowerShell Script Block Logging). Field: ScriptBlockText contains any of: TrustedForDelegation, TrustedToAuthForDelegation, msDS-AllowedToDelegateTo, PrincipalsAllowedToDelegateToAccount, or the LDAP filter userAccountControl:1.2.840.113556.1.4.803:=524288.
• High-Frequency Authentication Failures with Valid Username Pattern: Log source: SignInLogs. Fields: ResultType IN (50126, 50053) AND UserDisplayName is populated (confirming the username resolved). Multiple failures against different accounts from the same IPAddress within a 5-minute window suggest enumeration or credential stuffing.
• SSPR Endpoint Probing: Log source: Proxy or WAF logs. Field: url contains passwordreset.microsoftonline.com/common/userrealm with high request volume from a single external IP. The userrealm endpoint reveals whether a username is a managed or federated account without authentication.
• Suspicious Parent Process for PowerShell AD Enumeration: Log source: Windows Sysmon Event ID 1 (Process Create) or Windows Security Event ID 4688. Field: CommandLine contains Get-ADComputer or Get-ADUser AND ParentImage is not a known admin tool (e.g., parent is cmd.exe, wscript.exe, or a user-facing application rather than powershell_ise.exe or a management console).

Detection Logic

Rule 1 (Broad — High Sensitivity): Azure AD Leaked Credential Alert
IF riskEventType = "leakedCredentials" THEN alert(severity=HIGH, user=userPrincipalName)

This catches any Microsoft-confirmed credential exposure for your tenant's users. False positive rate is very low (near-zero per MITRE and Microsoft documentation — rare hash collisions are cited). Expected volume: low, typically single-digit events per month for most organizations. Treat every hit as requiring immediate investigation and forced password reset.

Rule 2 (Medium — Balanced): SSH Username Enumeration via CVE-2018-15473
IF log_source = "sshd" AND message CONTAINS "error: buffer_get_ret: trying to get more bytes 1907 than in buffer 308 [preauth]" AND COUNT(events) BY src_ip WITHIN 5 minutes >= 5 THEN alert(severity=MEDIUM, src_ip=src_ip)

Catches automated exploitation of the OpenSSH username enumeration vulnerability. A single occurrence could be a misconfigured client, but five or more in five minutes from the same source is almost certainly tooling. Expected volume: low on patched environments, higher if legacy SSH versions exist.

Rule 3 (Targeted — High Precision): PowerShell Active Directory Delegation Discovery
IF EventID = 4104 AND ScriptBlockText CONTAINS ANY ("TrustedForDelegation", "TrustedToAuthForDelegation", "msDS-AllowedToDelegateTo", "PrincipalsAllowedToDelegateToAccount", "userAccountControl:1.2.840.113556.1.4.803:=524288") AND user NOT IN [approved_ad_admins_group] THEN alert(severity=MEDIUM, host=Computer, user=UserID)

Targets post-compromise identity reconnaissance via PowerShell. This is a very specific query pattern rarely used by non-admin users. Expected volume: very low — flag every non-baseline hit for review.

Rule 4 (Broad — Credential Stuffing/Enumeration via Azure AD Sign-In Failures):
IF log_source = "SignInLogs" AND ResultType IN ("50126", "50053", "50055") AND COUNT(DISTINCT UserPrincipalName) BY IPAddress WITHIN 10 minutes >= 10 AND IPAddress NOT IN [known_corporate_egress_IPs] THEN alert(severity=HIGH, ip=IPAddress)

Detects credential stuffing or username enumeration attempts against your Azure AD login surface from external IPs. Hitting 10 or more distinct accounts in 10 minutes from a single IP is rarely legitimate. Expected volume: moderate in environments without conditional access policies; tune the threshold based on your baseline authentication failure rate.

Tuning Guidance

• IT Admin PowerShell Use: Active Directory admins routinely query delegation settings during infrastructure reviews. Exclude known admin accounts and hosts: add user IN [AD_Admin_ServiceAccounts] or host IN [jump_servers, admin_workstations] to the delegation discovery rule. Maintain a documented allowlist and review it quarterly.
• Vulnerability Scanners and Pen Test Tools: Internal scanners (Nessus, Qualys) or authorized red team engagements may trigger the SSH enumeration rule. Exclude known scanner source IPs: src_ip NOT IN [internal_scanner_IPs]. Always coordinate with your vulnerability management team to get scanner IP ranges before deploying the rule.
• Azure AD Sign-In Failures from Corporate VPN/NAT: Large organizations with shared egress IPs may generate many authentication failures legitimately. Add IPAddress NOT IN [corporate_NAT_ranges] and consider using UserAgent filtering to separate known client apps from headless scripting patterns (e.g., UserAgent NOT CONTAINS "python-requests" for the legitimate side).
• SSPR Probing False Positives from Password Managers: Some enterprise password managers probe the SSPR endpoint at login. Identify the source IPs or user agents of your deployed password manager and exclude them from SSPR-based rules: UserAgent NOT IN [known_password_manager_agents].
• Leaked Credential False Positives: Microsoft acknowledges that rare hash collisions can produce false positives for the leakedCredentials risk type. If a user reports no credential reuse and the password is confirmed unique, document it and dismiss in Identity Protection — but still require a password reset as a precaution.

When the Alert Fires: Investigation Steps

1. Verify the alert is real by confirming the raw event in the source log. For Azure AD leaked credential alerts, pull the raw event from AADRiskDetections in Sentinel or the Entra ID portal under Identity Protection → Risk Detections and confirm the riskEventType, timestamp, and affected userPrincipalName are accurate and not a duplicate or ingestion artifact.
2. Identify the affected user and determine privilege level. Query IdentityInfo (Sentinel) or your HR/AD directory to check whether the flagged account holds elevated roles — check Azure AD role assignments, on-prem AD group membership (especially Domain Admins, Global Admins, or service account roles), and whether the account has access to sensitive systems or data stores.
3. Pull the full command-line and parent process chain for any host-based indicators. For PowerShell Script Block events (Event ID 4104), retrieve the full ScriptBlockText and cross-reference with Sysmon Event ID 1 (Process Create) to reconstruct the parent process chain — identify what launched PowerShell, from where, and under whose credentials. Flag anomalous parents like winword.exe, outlook.exe, or mshta.exe.
4. Review authentication logs for signs of credential use following the enumeration. Query SignInLogs for the affected UserPrincipalName for the 72 hours following the enumeration alert. Look for successful logins from new or unusual IPAddress values, new DeviceDetail.deviceId values, unexpected geographic locations, or logins outside normal business hours using the ConditionalAccessStatus and Location fields.
5. Check for network connections from enumeration hosts and any files written to disk. For host-based detections, use Sysmon Event ID 3 (Network Connection) to identify outbound connections from the affected host around the same timestamp, and Event ID 11 (File Create) for any tools or output files dropped. Look for common staging paths like C:\Users\Public\, C:\Windows\Temp\, or %APPDATA%.
6. Search for lateral movement originating from the affected host or account. Query Windows Security Event ID 4624 (logon type 3 = network, type 10 = remote interactive) and 4648 (explicit credential use) for the affected username across all domain controllers and servers in your environment. Cross-reference with any new RDP sessions (Event ID 4778), WMI activity, or remote PowerShell sessions (Event ID 4103) from the same source host.
7. Make the escalation decision based on the totality of evidence. If enumeration activity is followed by a successful login from a new location, any credential reuse, lateral movement, or new persistence mechanisms — escalate immediately to a confirmed incident and engage the incident response process. If the enumeration is isolated with no subsequent authentication activity and originates from a known pen test engagement or authorized scanner, document and close with tuning recommendations.

Response Playbook

Containment

• Isolate the affected host (if host-based activity is confirmed): Quarantine the endpoint via your EDR platform (CrowdStrike Network Containment, Defender for Endpoint Isolate Device, or Carbon Black Device Quarantine). Leave the system powered on to preserve volatile memory for forensics. Do not reimage until memory acquisition is complete.
• Disable the affected user account immediately: In Entra ID, navigate to Users → select user → Edit → Account Status → Disabled, or run Update-MgUser -UserId -AccountEnabled $false via Microsoft Graph PowerShell. For on-prem AD, run Disable-ADAccount -Identity on a domain controller.
• Revoke all active sessions and tokens for the affected account: In Entra ID, go to the user's profile → Revoke Sessions, or use Revoke-MgUserSignInSession -UserId . This invalidates all active refresh tokens and forces reauthentication. Also revoke any application-specific OAuth tokens visible under the user's app registrations.
• Block identified attacker IPs at the perimeter: Add the source IPs identified in the enumeration activity to your firewall deny list and DNS sinkhole. For Azure-based attacks, block at the Conditional Access level by creating a Named Location for the attacker IP ranges and excluding it from all sign-in policies. Notify your ISP or report to abuse contacts if appropriate.
• Force MFA re-registration if MFA configuration may have been exposed: If the reconnaissance targeted MFA methods (e.g., via SSPR probing), disable the user's current MFA methods and require re-registration through a verified out-of-band channel before restoring access.

Eradication

• Remove any persistence mechanisms identified during investigation: Check Scheduled Tasks (Event ID 4698, schtasks /query), Registry Run keys (HKCU\Software\Microsoft\Windows\CurrentVersion\Run), new Services (Event ID 7045), and WMI subscriptions (Get-WMIObject -Namespace root\subscription -Class __EventFilter). Remove any entries not matching your approved baseline.
• Delete any tools or payload files dropped on disk: Based on Sysmon Event ID 11 findings, locate and delete dropped files. Search common staging paths using your EDR's file search capability. Submit any unknown binaries to a sandboxed analysis environment (ANY.RUN, VirusTotal, or an internal detonation chamber) before deletion to extract additional IOCs.
• Reset credentials for all affected accounts: Force a password reset for the compromised user through a secure, verified channel. If the account is a service account, rotate its password in all dependent systems and secrets vaults. If Kerberos tickets may have been issued using the exposed account, run Invoke-ADFSDiagnosticsCheck or force a KRBTGT key reset if a domain admin account was involved.
• Audit for additional backdoors on lateral movement targets: On any systems the affected user or host touched after the enumeration event, run your EDR's live response to check for new local admin accounts (Event ID 4720 + 4732), unauthorized SSH authorized_keys entries, or new scheduled tasks. Prioritize systems with sensitive data or elevated access.
• Rotate any API keys, secrets, or credentials that may have been exposed: If the enumeration targeted service accounts or the user had access to secrets management systems (Azure Key Vault, HashiCorp Vault, AWS Secrets Manager), rotate all associated secrets. Audit the secrets manager access logs for unauthorized reads around the timeframe of the incident.

Recovery

• Verify the host is clean before reconnecting to the network: Run a full AV and EDR scan on the isolated host. If confidence in a clean state is less than 100% — especially if the host was used post-enumeration for any attacker actions — reimage from a known-good golden image rather than attempting manual cleanup. Confirm with your EDR that no active threats are present before lifting network isolation.
• Re-enable the user account only after confirming no persistence remains: Before restoring access, confirm with the user's manager that the account's activity during the incident window has been fully reviewed, all sessions are clean, MFA has been re-enrolled via a verified channel, and the new password meets complexity requirements and has not been reused.
• Monitor the previously affected host and user for 72 hours post-remediation: Create a temporary, high-sensitivity watchlist in your SIEM scoped to the affected UserPrincipalName and host values. Alert on any new sign-in from unexpected locations, new process creation from unusual parents, or any outbound connection to previously unseen external IPs during this window.
• Document the full incident timeline and close with lessons learned: Record the initial alert time, discovery time, containment time, and eradication time. Document which detection rules fired, which didn't (and why), what data sources were missing, and what the attacker accomplished before being stopped. Share the timeline with the broader security team in a post-incident review within five business days.
• Update detection rules and coverage gaps based on new IOCs discovered: Add any new attacker IPs, user agent strings, tool signatures, or command patterns discovered during the investigation to your existing detection rules and threat intel platform. If new enumeration techniques were observed that your current ruleset missed, draft new detection logic and submit it for peer review before deploying to production.