T1589 Elastic Security · Elastic

Detect Gather Victim Identity Information in Elastic Security

This detection identifies adversary attempts to enumerate victim identity information—credentials, email addresses, and employee names—through active probing of authentication services and monitoring of downstream indicators of OSINT-driven targeting. Since T1589 is a PRE-ATT&CK technique occurring largely outside victim infrastructure, detection focuses on second-order observable signals: anomalous username enumeration via Azure AD sign-in failures with differential error codes (e.g., UserNameDoesNotExist vs. InvalidPassword), Self-Service Password Reset (SSPR) flow abuse, high-volume authentication probing from single sources against multiple distinct accounts, and MFA method enumeration patterns. Groups such as LAPSUS$, Scattered Spider, and HEXANE have exploited these mechanisms to build target identity lists before launching phishing, credential stuffing, or social engineering campaigns.

MITRE ATT&CK

Tactic
Reconnaissance
Technique
T1589 Gather Victim Identity Information
Canonical reference
https://attack.mitre.org/techniques/T1589/

Elastic Detection Query

Elastic Security (Elastic)
eql
/* T1589 - Victim Identity Enumeration via Differential Auth Error Codes */
/* Deploy as Threshold rule type: count_distinct(user.name) >= 15 grouped by source.ip over 1h */
any where
  (
    /* Azure AD / Entra ID sign-in failure via Elastic Azure integration */
    event.dataset == "azure.signinlogs" and
    event.outcome == "failure" and
    azure.signinlogs.properties.status.error_code in (50034, 50053, 50055, 50057, 50072, 50076) and
    source.ip != null and source.ip != "" and
    user.name != null and user.name != ""
  ) or (
    /* On-prem Windows NTLM logon failure - username does not exist or account disabled */
    event.code == "4625" and
    event.outcome == "failure" and
    winlog.event_data.SubStatus in (
      "0xc0000064", "0xC0000064",
      "0xc0000072", "0xC0000072",
      "0xc000006d", "0xC000006D"
    ) and
    source.ip != null and
    not cidr_match(source.ip, "127.0.0.0/8", "::1/128") and
    winlog.event_data.TargetUserName != null and
    winlog.event_data.TargetUserName != "-" and
    winlog.event_data.TargetUserName != "ANONYMOUS LOGON"
  ) or (
    /* Kerberos pre-auth failure - 0x6=ClientNotFound, 0x18=PasswordMismatch */
    event.code == "4771" and
    event.outcome == "failure" and
    winlog.event_data.Status in ("0x6", "0x18") and
    source.ip != null and
    not cidr_match(source.ip, "127.0.0.0/8", "::1/128") and
    winlog.event_data.TargetUserName != null and
    winlog.event_data.TargetUserName != "-"
  )
high severity high confidence

Detects T1589 victim identity enumeration via differential authentication error code analysis across both cloud (Azure AD/Entra ID) and on-premises identity providers. Matches Azure AD sign-in failures with error codes distinguishing non-existent users (50034), locked accounts (50053), expired passwords (50055), disabled accounts (50057), and MFA enumeration probes (50072/50076). Also matches Windows Security Event 4625 with SubStatus 0xC0000064 (user does not exist), 0xC0000072 (account disabled), and Kerberos Event 4771 with Status 0x6 (client not found) or 0x18 (wrong password). Must be deployed as a Threshold rule type in Elastic SIEM with count_distinct(user.name) >= 15 and count_distinct(user.name) as the unique key, grouped by source.ip over a 1-hour window, to replicate the aggregation logic from the reference KQL/SPL queries.

Data Sources

Azure Active Directory Sign-In Logs via Elastic Azure integration (azure.signinlogs)Windows Security Event Log via Winlogbeat or Elastic Agent (winlog)Elastic Agent with System integration (system.security)Microsoft 365 Defender data forwarded via Elastic integration

Required Tables

logs-azure.signinlogs-*logs-system.security-*winlogbeat-*.ds-logs-system.security-*

False Positives & Tuning

  • Authorized penetration testing or red team exercises performing Active Directory account enumeration from known internal jump hosts or CIDR ranges — create rule exceptions for pre-approved test source IPs during engagement windows
  • Legacy enterprise applications (ERP, ITSM) with hardcoded service account credential arrays that rotate through dozens of accounts during startup or scheduled synchronization jobs, producing burst authentication failures from a single host IP
  • Helpdesk and IAM provisioning platforms (ServiceNow, SailPoint, Saviynt) that validate username existence across large employee batches during bulk onboarding or offboarding processing cycles
  • Password expiry notification services that probe account status for all users nearing expiry and generate incidental authentication failures for already-expired or locked accounts
  • Security operations tooling such as SOAR playbooks or UEBA enrichment services that query identity providers to resolve user context for unrelated alerts, producing spurious failures against inactive or service accounts
Download portable Sigma rule (.yml)

Other platforms for T1589


Testing Methodology

Validate this detection against 3 adversary techniques from Atomic Red Team. Each test below lists the behaviour to exercise and the telemetry you should expect to see. Executable commands and cleanup steps are available with Pro.

  1. Test 1Azure AD Username Enumeration via GetCredentialType API

    Expected signal: Azure AD Sign-in Logs (AADSignInLogs) will show ResultType=50034 (UserNameDoesNotExist) for non-existent accounts. Successful lookups may show ResultType=0 or MFA-related codes. Source IP will be the test machine's public IP. Check Azure AD portal under Monitoring > Sign-in Logs filtering by the test domain.

  2. Test 2On-Premises Active Directory Username Enumeration via Kerberos

    Expected signal: Windows Security Event ID 4625 with SubStatus 0xc0000064 (user does not exist) on domain controller for each non-existent username tested. Event ID 4625 with SubStatus 0xc000006a (wrong password) for valid usernames. Event ID 4771 with Status 0x6 on DCs running Kerberos logging. Check DC Security event logs filtering: EventID=4625 AND (SubStatus=0xc0000064 OR SubStatus=0xc0000072).

  3. Test 3SSPR Username Existence Probing via Azure AD Password Reset Flow

    Expected signal: Azure AD Audit Logs will contain SSPR-related entries under 'Self-service password reset flow activity' and 'Verify email address phone number'. Check Azure portal: Azure Active Directory > Monitoring > Audit Logs, filter Activity='Reset password (self-service)' or 'Self-service password management'. In Sentinel: AuditLogs | where OperationName contains 'password' | where TimeGenerated > ago(1h)

Unlock Pro Content

Get the full detection package for T1589 including response playbook, investigation guide, and atomic red team tests.

Response PlaybookInvestigation GuideHunting QueriesAtomic Red Team TestsTuning Guidance

Related Detections