Which SIEM platforms have a T1586 detection rule?

df00tech provides T1586 (Compromise Accounts) detection queries for 7 SIEM platforms: Microsoft Sentinel / Defender, Splunk, Elastic Security (EQL), IBM QRadar (AQL), Sumo Logic CSE, Google Chronicle / SecOps, CrowdStrike LogScale (CQL).

What data sources are required to detect Compromise Accounts (T1586)?

Detecting Compromise Accounts requires the following data sources: Azure Active Directory, Microsoft Entra ID.

What severity and confidence is the T1586 detection?

The T1586 detection is rated high severity with medium confidence.

What are common false positives for T1586?

Common false positives for T1586 include: Legitimate corporate VPN services routing authentication through shared exit nodes may match ASN-based detection; allowlist known corporate egress IP ranges; Traveling employees authenticating from multiple countries within a short window (e.g. connecting through an airline hub) will trigger impossible travel; cross-reference with HR travel records and conditional access named locations; Shared service accounts used by automation platforms (CI/CD, monitoring) may generate high failure counts if misconfigured credentials are in rotation before being corrected; baseline service account authentication patterns.

T1586

Compromise Accounts

Resource Development Last updated: April 13, 2026

This detection identifies indicators of compromised accounts being leveraged against the organization, including credential stuffing attacks that transition from repeated failures to success, impossible travel anomalies where a single identity authenticates from geographically distant locations within an implausible timeframe, sign-ins from known hosting or anonymization infrastructure, and MFA bypass patterns consistent with session token theft or adversary-in-the-middle phishing toolkits such as Evilginx2 or Modlishka. Because T1586 is a PRE-ATT&CK technique occurring outside the victim environment, detections focus on the observable authentication artifacts generated when adversaries weaponize stolen credentials or session material against organizational identity providers including Azure AD, on-premises Active Directory, and SaaS application login flows.

What is T1586 Compromise Accounts?

Compromise Accounts (T1586) maps to the Resource Development tactic — the adversary is trying to establish resources they can use to support operations in MITRE ATT&CK.

This page provides production-ready detection logic for Compromise Accounts, covering the data sources and telemetry it touches: Azure Active Directory, Microsoft Entra ID. The queries below are rated high severity at medium confidence, and ship for 7 SIEM platforms — KQL, SPL, Elastic, QRadar, Sumo, YARA-L, LogScale.

MITRE ATT&CK

Tactic: Resource Development
Technique: T1586 Compromise Accounts
Canonical reference: https://attack.mitre.org/techniques/T1586/

Microsoft Sentinel / Defender

kusto

let timeWindow = 24h;
let failThreshold = 5;
let travelWindowMinutes = 60;
// --- Signal 1: Credential stuffing — many failures then success from multiple IPs ---
let CredentialStuffing = AADSignInLogs
| where TimeGenerated > ago(timeWindow)
| where ResultType != "50053" and ResultType != "50076" // exclude locked-out and MFA-required noise
| summarize
    FailureCount = countif(ResultType != "0"),
    SuccessCount = countif(ResultType == "0"),
    UniqueIPs = dcount(IPAddress),
    IPList = make_set(IPAddress, 10),
    Apps = make_set(AppDisplayName, 5),
    FirstSeen = min(TimeGenerated),
    LastSeen = max(TimeGenerated)
    by UserPrincipalName
| where FailureCount >= failThreshold and SuccessCount >= 1
| extend DetectionType = "CredentialStuffing",
    RiskScore = iff(UniqueIPs > 5, 90, iff(UniqueIPs > 2, 75, 60));
// --- Signal 2: Impossible travel — successful logins from 2+ countries within 60 minutes ---
let ImpossibleTravel = AADSignInLogs
| where TimeGenerated > ago(timeWindow)
| where ResultType == "0"
| where isnotempty(Location)
| extend Country = tostring(LocationDetails.countryOrRegion)
| where isnotempty(Country)
| summarize
    Countries = make_set(Country, 20),
    IPList = make_set(IPAddress, 10),
    Apps = make_set(AppDisplayName, 5),
    FirstSeen = min(TimeGenerated),
    LastSeen = max(TimeGenerated),
    SuccessCount = count()
    by UserPrincipalName, bin(TimeGenerated, 1h)
| where array_length(Countries) > 1
| extend DetectionType = "ImpossibleTravel", RiskScore = 85,
    FailureCount = 0, UniqueIPs = array_length(IPList);
// --- Signal 3: Successful login from Tor exit node or known bulletproof hosting ASN ---
let SuspiciousASN = AADSignInLogs
| where TimeGenerated > ago(timeWindow)
| where ResultType == "0"
| extend ASN = tostring(todynamic(NetworkLocationDetails)[0].networkNames)
| where ASN has_any ("M247", "Frantech", "Sharktech", "Psychz", "Quasi Networks",
    "FranTech", "Alexhost", "ITL-Bulgaria", "Serverius", "Combahton")
    or IPAddress matches regex @"^185\.(220|129|220)\."
| summarize
    IPList = make_set(IPAddress, 10),
    Apps = make_set(AppDisplayName, 5),
    FirstSeen = min(TimeGenerated),
    LastSeen = max(TimeGenerated),
    SuccessCount = count(),
    Countries = make_set(tostring(LocationDetails.countryOrRegion), 5)
    by UserPrincipalName
| extend DetectionType = "SuspiciousHostingASN", RiskScore = 80,
    FailureCount = 0, UniqueIPs = array_length(IPList);
// --- Union all signals ---
CredentialStuffing
| union ImpossibleTravel
| union SuspiciousASN
| project
    TimeGenerated = LastSeen,
    UserPrincipalName,
    DetectionType,
    RiskScore,
    FailureCount,
    SuccessCount,
    UniqueIPs,
    IPList,
    Apps,
    Countries,
    FirstSeen,
    LastSeen
| sort by RiskScore desc, TimeGenerated desc

Detects three distinct compromise account patterns against Azure AD: (1) credential stuffing where 5+ authentication failures from multiple IPs precede a successful login, (2) impossible travel where a single identity successfully authenticates from two or more countries within a 60-minute window, and (3) successful logins sourced from known bulletproof hosting or anonymization ASNs associated with threat actor infrastructure. Results are scored by risk level to prioritize analyst triage.

high severity medium confidence

Data Sources

Azure Active Directory Microsoft Entra ID

Required Tables

AADSignInLogs

False Positives

Legitimate corporate VPN services routing authentication through shared exit nodes may match ASN-based detection; allowlist known corporate egress IP ranges
Traveling employees authenticating from multiple countries within a short window (e.g. connecting through an airline hub) will trigger impossible travel; cross-reference with HR travel records and conditional access named locations
Shared service accounts used by automation platforms (CI/CD, monitoring) may generate high failure counts if misconfigured credentials are in rotation before being corrected; baseline service account authentication patterns
Password reset self-service workflows may generate multiple ResultType failures before a successful reset, mimicking credential stuffing; filter on UserType and correlate with SSPR audit events in AuditLogs

Splunk

spl

index=* (sourcetype="WinEventLog:Security" OR sourcetype="XmlWinEventLog:Security")
    EventCode IN (4624, 4625, 4648, 4776)
| eval AuthResult=case(
    EventCode=="4624", "Success",
    EventCode=="4625", "Failure",
    EventCode=="4648", "ExplicitCred",
    EventCode=="4776", "KerberosValidation",
    true(), "Unknown"
  )
| eval TargetUser=coalesce('TargetUserName', 'Account_Name')
| where TargetUser!="-" AND TargetUser!="" AND NOT match(TargetUser, "^\$$")
| eval IpAddress=coalesce('IpAddress', 'Source_Network_Address')
| eval IpAddress=if(IpAddress=="-" OR IpAddress="127.0.0.1" OR IpAddress="::1", null(), IpAddress)
| stats
    count(eval(AuthResult=="Failure")) AS FailureCount,
    count(eval(AuthResult=="Success" OR AuthResult=="ExplicitCred")) AS SuccessCount,
    dc(IpAddress) AS UniqueIPs,
    values(IpAddress) AS IPList,
    values(WorkstationName) AS WorkstationList,
    min(_time) AS FirstSeen,
    max(_time) AS LastSeen
    by TargetUser, TargetDomainName
| where FailureCount >= 5 AND SuccessCount >= 1
| eval WindowMinutes=round((LastSeen - FirstSeen) / 60, 1)
| eval RiskScore=case(
    UniqueIPs > 10, 95,
    UniqueIPs > 5, 85,
    UniqueIPs > 2, 70,
    true(), 55
  )
| eval DetectionType="CredentialStuffingThenSuccess"
| table TargetUser, TargetDomainName, FailureCount, SuccessCount, UniqueIPs,
    IPList, WorkstationList, WindowMinutes, RiskScore, DetectionType, FirstSeen, LastSeen
| sort - RiskScore

Detects credential stuffing and account compromise patterns using Windows Security event logs by correlating authentication failures (EventID 4625, 4776) with subsequent successes (EventID 4624, 4648) per user account. Flags accounts with 5 or more failures followed by at least one success, enriches with unique source IP count for risk scoring, and surfaces the source workstations and IP addresses for rapid analyst triage.

high severity medium confidence

Data Sources

Windows Security Event Logs Active Directory

Required Sourcetypes

WinEventLog:Security XmlWinEventLog:Security

False Positives

Service accounts with stale cached credentials during password rotation will generate failure spikes followed by a successful login once credentials are updated; maintain a service account allowlist and correlate with change management windows
Kerberos pre-authentication failures (EventCode 4771) for accounts with clock skew or misconfigured SPNs may appear before a successful 4624; verify Kerberos failure sub-status codes and correlate with DC time sync logs
Domain controller replication events and inter-domain trust authentication can produce 4776 failures from machine accounts before succeeding; filter TargetUserName ending in '$' to exclude machine accounts

Elastic Security (EQL)

eql

/* Signal 1: Credential Stuffing — 5+ failures then success within 24h */
sequence by user.name with maxspan=24h
  [authentication where event.outcome == "failure"
    and not (event.provider : "azure_ad"
      and error.code : ("50053", "50076"))]
  with runs=5
  [authentication where event.outcome == "success"]

/* Signal 2: Successful login from bulletproof / anonymisation ASN — deploy as a separate detection rule:
authentication where event.outcome == "success"
  and source.as.organization.name : (
    "M247*", "Frantech*", "Sharktech*", "Psychz*",
    "Quasi Networks*", "Alexhost*", "Serverius*", "Combahton*",
    "FranTech*", "ITL-Bulgaria*"
  )
  and user.name != null
  and user.domain != null
*/

/* Signal 3: Impossible travel — two successful logins from different countries
   within 60 min cannot be expressed in EQL (no multi-event aggregation).
   Implement as an ES|QL query:
   FROM logs-azure.signinlogs-*
   | WHERE event.outcome == "success"
     AND source.geo.country_iso_code IS NOT NULL
   | STATS countries = COUNT_DISTINCT(source.geo.country_iso_code),
           ip_list = VALUES(source.ip)
     BY user.name, BUCKET(@timestamp, 1 hour)
   | WHERE countries > 1
*/

Detects T1586 Compromise Accounts via two deployable signals. Signal 1 uses an EQL sequence to identify credential stuffing: five or more authentication failures followed by a successful login for the same identity within 24 hours, skipping Azure AD lockout and MFA-challenge noise codes 50053 and 50076. Signal 2 (included as a comment for separate deployment) fires on any successful authentication originating from ASNs associated with bulletproof hosting or anonymisation infrastructure. Signal 3 (impossible travel) requires ES|QL due to EQL's event-centric model and is provided as a companion query. The sequence approach minimises false positives by requiring the success to follow the failures rather than treating them independently.

high severity high confidence

Data Sources

Microsoft Azure AD Sign-in Logs (azure.signinlogs) Microsoft Entra ID (entra.signinlogs) Windows Security Event Log via Winlogbeat or Elastic Agent Okta System Log via Elastic integration

Required Tables

logs-azure.signinlogs-* logs-azure.auditlogs-* winlogbeat-* .ds-logs-system.auth-* logs-okta.system-*

False Positives

Authorised red-team or penetration-testing exercises deliberately generating credential stuffing patterns against internal accounts — confirm against a known-testing calendar before escalating
Corporate VPN or cloud proxy services whose exit nodes are hosted on ASNs flagged as bulletproof hosting (M247 carries significant legitimate SaaS traffic); validate by correlating the device identity and enriching the IP against threat-intel feeds rather than relying solely on ASN name
Users who forget their password on a Monday morning and attempt several times before successfully using a self-service reset link, producing the failure-then-success pattern from a single residential IP
Service accounts with scheduled tasks carrying a stale password that retry authentication until the credential rotation cycle completes and the new secret is injected
Password-change flows in Azure AD that briefly invalidate the session token and trigger a transient 401/failure before the new credential is accepted

IBM QRadar (AQL)

sql

SELECT
  username,
  domainid,
  FailureCount,
  SuccessCount,
  UniqueSourceIPs,
  FirstSeen,
  LastSeen,
  CASE
    WHEN UniqueSourceIPs > 10 THEN 95
    WHEN UniqueSourceIPs > 5  THEN 85
    WHEN UniqueSourceIPs > 2  THEN 70
    ELSE 55
  END AS RiskScore,
  'CredentialStuffingThenSuccess' AS DetectionType
FROM (
  SELECT
    username,
    domainid,
    SUM(CASE WHEN category = 5002 THEN 1 ELSE 0 END)  AS FailureCount,
    SUM(CASE WHEN category = 5000 THEN 1 ELSE 0 END)  AS SuccessCount,
    UNIQUECOUNT(sourceip)                             AS UniqueSourceIPs,
    DATEFORMAT(MIN(starttime), 'yyyy-MM-dd HH:mm:ss') AS FirstSeen,
    DATEFORMAT(MAX(starttime), 'yyyy-MM-dd HH:mm:ss') AS LastSeen
  FROM events
  WHERE
    username IS NOT NULL
    AND username NOT IN ('-', '', 'N/A', 'SYSTEM', 'anonymous logon', 'ANONYMOUS LOGON')
    AND username NOT LIKE '%$'
    AND category IN (5000, 5002)
    AND starttime > NOW() - 86400000
  GROUP BY username, domainid
  HAVING
    SUM(CASE WHEN category = 5002 THEN 1 ELSE 0 END) >= 5
    AND SUM(CASE WHEN category = 5000 THEN 1 ELSE 0 END) >= 1
) AS CredentialStuffing
ORDER BY RiskScore DESC, FailureCount DESC

QRadar AQL query detecting T1586 credential stuffing by aggregating QRadar high-level category 5000 (Authentication Success) and 5002 (Authentication Failed) events over a rolling 24-hour window. Uses a subquery to compute per-account failure and success counts and unique source IPs, then applies risk scoring in the outer query. Machine accounts (username ending in $) and built-in system accounts are excluded. Map this query to a Custom Rule with an offense threshold of 1 and a time-based correlation window of 24 hours. Covers all log sources QRadar normalises to category 5000/5002, including Windows Security Event Log (DSM ID 12), Azure AD, and Okta DSM. For impossible-travel coverage, add a second AQL rule grouping by username and LOGSOURCEID filtered to logins with different CATEGORY_NAME values for the country field extracted via a custom event property.

high severity high confidence

Data Sources

Windows Security Event Log (QRadar DSM 12) Microsoft Azure Active Directory (QRadar DSM 352) Okta (QRadar DSM 617) IBM Security Identity and Access Assurance

Required Tables

events

False Positives

Helpdesk-assisted password resets where a support agent attempts authentication multiple times on behalf of an end user from the helpdesk workstation IP before succeeding, producing 5+ failures followed by a success under a single username
Automated deployment or CI/CD pipelines carrying stale service-account credentials that cycle through connection retries before a secrets-manager refresh injects the current token, generating repeated failure events in quick succession
QRadar log-source misconfiguration where a shared NAT egress IP aggregates authentication attempts from dozens of internal endpoints, inflating UniqueSourceIPs and producing risk-score spikes that do not reflect actual multi-source attacks

Sumo Logic CSE

sql

(_sourceCategory="os/windows/security"
  OR _sourceCategory="azure/signinlogs"
  OR _sourceCategory="okta/systemlog")
| parse field=_raw "EventCode=*" as EventCode nodrop
| parse field=_raw "\"resultType\":\"*\"" as ResultType nodrop
| parse field=_raw "TargetUserName=*\n" as TargetUser nodrop
| parse field=_raw "\"userPrincipalName\":\"*\"" as UPN nodrop
| parse field=_raw "IpAddress=*\n" as WinIP nodrop
| parse field=_raw "\"ipAddress\":\"*\"" as AzureIP nodrop
| eval AuthUser = if(!isNull(UPN) and UPN != "", UPN, TargetUser)
| eval SrcIP = if(!isNull(AzureIP) and AzureIP != "", AzureIP, WinIP)
| eval IsFailure = if(
    EventCode in ("4625", "4776")
    or (ResultType != "0" and !isNull(ResultType)
        and ResultType != "50053" and ResultType != "50076"),
    1, 0)
| eval IsSuccess = if(
    EventCode in ("4624", "4648")
    or ResultType == "0",
    1, 0)
| where !isNull(AuthUser)
  and AuthUser != "-"
  and AuthUser != ""
  and !matches(AuthUser, ".*\\$$")
| stats
    sum(IsFailure)         as FailureCount,
    sum(IsSuccess)         as SuccessCount,
    dcount(SrcIP)          as UniqueIPs,
    values(SrcIP)          as IPList,
    min(_messageTime)      as FirstSeen,
    max(_messageTime)      as LastSeen
    by AuthUser
| where FailureCount >= 5 and SuccessCount >= 1
| eval WindowMinutes = round((LastSeen - FirstSeen) / 60000, 1)
| eval RiskScore = if(UniqueIPs > 10, 95,
                   if(UniqueIPs > 5,  85,
                   if(UniqueIPs > 2,  70, 55)))
| eval DetectionType = "CredentialStuffingThenSuccess"
| fields AuthUser, FailureCount, SuccessCount, UniqueIPs, IPList,
         WindowMinutes, RiskScore, DetectionType, FirstSeen, LastSeen
| sort by RiskScore desc

Sumo Logic scheduled search detecting T1586 credential stuffing across Windows Security Event logs (EventCode 4624, 4625, 4648, 4776), Azure AD sign-in logs (resultType 0 = success), and Okta System Log entries. Uses nodrop parse statements to handle heterogeneous source formats without dropping non-matching events, normalises username and source IP fields across log types, then aggregates per account to identify accounts experiencing repeated authentication failures followed by success. Deploy as a scheduled search with a 24-hour time range running every 30 minutes. Adjust _sourceCategory values to match your collection configuration. For Cloud SIEM Enterprise (CSE) deployments replace extracted fields with normalised schema fields: user_username, srcDevice_ip, and normalizedAction fields provided by the CSE normalisation layer.

high severity medium confidence

Data Sources

Windows Security Event Log via Sumo Logic Installed Collector Azure Active Directory Sign-in Logs via Azure Monitor or Diagnostic Settings Okta System Log via Sumo Logic Okta App Microsoft 365 Unified Audit Log

Required Tables

_sourceCategory matching os/windows/security _sourceCategory matching azure/signinlogs _sourceCategory matching okta/systemlog

False Positives

Users who forget their password after a long weekend or holiday and attempt several times before successfully invoking self-service password reset, particularly common at domain logon from new devices where cached credentials are absent
Scheduled tasks or service accounts with a stale password configuration that retry on a fixed interval until a secret-rotation job updates the stored credential, generating burst failures before a single success
Multi-tenant Sumo Logic deployments sharing a single _sourceCategory across multiple organisations where a common username (e.g. admin, administrator) exists in multiple tenants, causing cross-tenant aggregation that artificially inflates FailureCount

Google Chronicle / SecOps

yaral

rule t1586_impossible_travel_authentication {
  meta:
    author          = "Argus Detection Engineering"
    description     = "Detects T1586 Compromise Accounts — impossible travel: a single identity authenticates successfully from two different countries within 60 minutes, strongly indicating stolen credentials or AiTM session-token theft via toolkits such as Evilginx2 or Modlishka"
    mitre_attack_tactic    = "Resource Development"
    mitre_attack_technique = "T1586"
    mitre_attack_subtechnique = "T1586.003"
    severity        = "CRITICAL"
    confidence      = "HIGH"
    reference       = "https://attack.mitre.org/techniques/T1586/"
    created         = "2025-01-01"

  events:
    // First successful authentication
    $e1.metadata.event_type = "USER_LOGIN"
    $e1.security_result.action = "ALLOW"
    $e1.principal.user.userid = $userid
    $e1.principal.location.country_or_region = $country1
    $country1 != ""
    $e1.principal.ip != ""

    // Second successful authentication — same user, different country
    $e2.metadata.event_type = "USER_LOGIN"
    $e2.security_result.action = "ALLOW"
    $e2.principal.user.userid = $userid
    $e2.principal.location.country_or_region = $country2
    $country2 != ""
    $e2.principal.ip != ""

    // Must originate from different countries
    $country1 != $country2

    // Second login must follow the first chronologically
    $e1.metadata.event_timestamp.seconds < $e2.metadata.event_timestamp.seconds

  match:
    $userid over 1h

  outcome:
    $risk_score      = max(90)
    $country_first   = array_distinct($e1.principal.location.country_or_region)
    $country_second  = array_distinct($e2.principal.location.country_or_region)
    $source_ips      = array_distinct($e1.principal.ip)
    $target_apps     = array_distinct($e1.target.application)

  condition:
    #e1 > 0 and #e2 > 0
}

Chronicle YARA-L 2.0 detection rule for T1586 using the impossible-travel signal: two UDM USER_LOGIN events with security_result.action ALLOW for the same userid but different principal.location.country_or_region values within a 60-minute match window. This pattern is a high-confidence indicator of credential theft or adversary-in-the-middle session hijacking, since no legitimate user can physically travel between countries in under an hour. The rule correlates events via the match block time window, binds the first and second login to separate event variables ($e1/$e2), and enforces chronological ordering. For credential-stuffing coverage deploy a companion rule that matches on #fail >= 5 and #success >= 1 for the same userid over 24h using security_result.action BLOCK and ALLOW respectively. Chronicle's UDM normalisation layer ingests Azure AD, Google Workspace, and Okta sources and maps them to the USER_LOGIN event type automatically.

critical severity high confidence

Data Sources

Google Workspace Activity via Chronicle ingestion Azure Active Directory Sign-in Logs via Chronicle ingestion Okta System Log via Chronicle SIEM connector Microsoft Entra ID via Google Chronicle

Required Tables

UDM events of type USER_LOGIN

False Positives

Corporate VPN services with geographically distributed exit nodes where a user connects to two different VPN gateways in sequence — the identity provider sees authentication from two countries while the user has not moved
CDN or reverse-proxy infrastructure that rewrites the source IP on authenticated API calls, causing the second programmatic authentication to appear to originate from the CDN's country rather than the user's country
Automated CI/CD or API integration service accounts that authenticate from cloud infrastructure in one AWS or GCP region while a developer simultaneously authenticates from their home country, both using the same service-account identity

CrowdStrike LogScale (CQL)

cql

// T1586 Compromise Accounts — Credential Stuffing via Falcon Identity Protection telemetry
#event_simpleName in ("UserLogon", "UserLogonFailed2", "AuthActivityAuditEvent")
| case {
    #event_simpleName = "UserLogon"        | IsSuccess := 1 | IsFailure := 0 ;
    #event_simpleName = "UserLogonFailed2" | IsSuccess := 0 | IsFailure := 1 ;
    *                                       | IsSuccess := 0 | IsFailure := 0 ;
  }
// Exclude machine accounts and empty usernames
| UserName != ""
| UserName != "-"
| not regex("^.+\\$$", field=UserName)
| groupBy(
    [UserName, UserDomain],
    function=[
      sum(IsFailure,   as=FailureCount),
      sum(IsSuccess,   as=SuccessCount),
      uniqueCount(RemoteAddressIP4, as=UniqueSourceIPs),
      collect(RemoteAddressIP4, limit=10, as=IPList),
      min(@timestamp,  as=FirstSeen),
      max(@timestamp,  as=LastSeen)
    ]
  )
// Apply thresholds matching the KQL/SPL originals
| FailureCount >= 5
| SuccessCount >= 1
// Risk scoring scaled to unique source IP spread
| RiskScore := if(UniqueSourceIPs > 10, 95,
               if(UniqueSourceIPs > 5,  85,
               if(UniqueSourceIPs > 2,  70, 55)))
| WindowMinutes := (LastSeen - FirstSeen) / 60000
| DetectionType := "CredentialStuffingThenSuccess"
| sort(RiskScore, order=desc)

CrowdStrike Falcon LogScale query correlating UserLogon (success) and UserLogonFailed2 (failure) events from Falcon's endpoint telemetry and Identity Protection module. Pre-classifies each event as success or failure using a case expression, excludes machine accounts and empty usernames, then groups by username and domain to compute failure count, success count, unique source IPs, and time window. Applies the same thresholds as the originating KQL and SPL queries (FailureCount >= 5, SuccessCount >= 1) and produces a risk score scaled to IP spread. Requires Falcon Identity Threat Detection (ITD) or Falcon Identity Protection licensing for domain-joined Windows endpoints; cloud identity provider sign-in events (Azure AD, Okta) are available when the Falcon Identity connector is configured. Save as a Scheduled Alert with a 24-hour lookback window and alert on any result. For ASN-based detection, supplement with an ExternalIP enrichment lookup and filter on ASN names matching bulletproof hosting providers.

high severity medium confidence

Data Sources

CrowdStrike Falcon Identity Threat Detection (ITD) CrowdStrike Falcon Insight XDR endpoint telemetry CrowdStrike Falcon Identity Protection — Azure AD connector CrowdStrike Falcon Identity Protection — Okta connector

Required Tables

Falcon telemetry: UserLogon Falcon telemetry: UserLogonFailed2 Falcon telemetry: AuthActivityAuditEvent

False Positives

Endpoint provisioning or imaging workflows where automated scripts attempt domain authentication from a freshly joined machine before the credential is fully propagated through AD replication, producing several Kerberos pre-authentication failures before the first successful logon
Falcon sensor deployment on shared RDS or Citrix terminal servers where multiple users log in sequentially during a peak business window — session-count policies may reject the first few attempts as FAILURE events before one session slot opens and succeeds
Domain-trust validation or SCCM/MECM network discovery scans that probe authentication endpoints on a fixed schedule using service-account credentials, generating periodic bursts of failure events if the discovery target has a different authentication policy than expected

Sigma rule & cross-platform mapping

The detection logic for Compromise Accounts (T1586) above is provided in a vendor-neutral form so you can deploy it on any SIEM. The same logic is shipped here as native KQL (Microsoft Sentinel / Defender), SPL (Splunk), Elastic (Elastic Security (EQL)), QRadar (IBM QRadar (AQL)), Sumo (Sumo Logic CSE), YARA-L (Google Chronicle / SecOps), LogScale (CrowdStrike LogScale (CQL)) queries. In Sigma terms, this detection targets the following logsource:

logsource:
  product: azure

Browse the community-maintained Sigma rules for this technique:

SigmaHQ rules for T1586 Sigma rules on detection.fyi

Platform-specific guides for T1586

Detect in Microsoft Sentinel (KQL) Detect in Splunk (SPL) Detect in Elastic Security (Elastic) Detect in IBM QRadar (QRadar) Detect in Sumo Logic CSE (Sumo) Detect in Google Chronicle (YARA-L) Detect in CrowdStrike LogScale (LogScale)

Last updated: 2026-04-13 Research depth: deep

References (5)

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.

Test 1Simulate credential stuffing authentication pattern using PowerShell against Azure AD
Expected signal: AADSignInLogs will show 6 ResultType != 0 events followed by 1 ResultType == 0 event for the test UPN from the same source IP within a short time window. RiskState may update in AADRiskyUsers within 15-30 minutes.
Test 2Simulate legacy protocol authentication bypass against Exchange Online (SMTP AUTH)
Expected signal: AADSignInLogs entry with ClientAppUsed='Authenticated SMTP', AuthenticationRequirement='singleFactorAuthentication', ResultType=0 for the test account. This event will NOT appear in modern auth logs, validating the legacy auth gap.
Test 3Simulate account compromise indicators via failed then successful Windows network logon from multiple sources
Expected signal: Windows Security EventID 4625 (LogonType 3, SubStatus 0xC000006A = wrong password) six times followed by EventID 4624 (LogonType 3) once for the test account in the domain controller Security event log. Source workstation will be the executing host.

Response Playbook

Triage

Step 1 — Identify the detection subtype (CredentialStuffing, ImpossibleTravel, SuspiciousASN) and pull the full sign-in log for the flagged UserPrincipalName covering the past 72 hours. Note all source IPs, user agents, client application IDs, and conditional access outcomes.
Step 2 — For CredentialStuffing: check whether the failures preceded the success by a consistent interval (automated tooling) or appear random (manual); extract the User-Agent header from AADSignInLogs to identify known attack frameworks (e.g., python-requests, curl, go-http).
Step 3 — For ImpossibleTravel: calculate the physical distance between the two authentication locations and the time delta. If a human cannot travel that distance in that time, treat as confirmed compromise. Cross-reference with the user's recent travel requests in HR systems or calendar.
Step 4 — Query OfficeActivity and CloudAppEvents for the user for the 48 hours following the suspicious successful login. Look for mass email access, large file downloads, permission changes, or OAuth app consent grants that occurred under the compromised session.
Step 5 — Check AuditLogs for MFA registration changes, password resets, conditional access named location changes, or trusted device additions that occurred within 30 minutes of the suspicious successful login — these indicate the adversary is establishing persistence.
Step 6 — Correlate the source IP(s) against threat intelligence feeds (VirusTotal, Shodan, AbuseIPDB, Spamhaus) to assess whether it belongs to a residential proxy network, VPN exit node, or known C2 infrastructure. Check if the same IP appeared in failed logins against other accounts.

Containment

Immediately revoke all active sessions for the compromised account using the Microsoft Entra admin center (Users → Sign-in logs → Revoke sessions) or via PowerShell: Revoke-AzureADUserAllRefreshToken -ObjectId <UPN>.
Force a password reset via Azure AD admin portal and require re-registration of MFA methods. If the account has Global Administrator or privileged roles, escalate immediately and consider temporary account disable pending investigation.
Apply a Conditional Access policy to restrict the account to compliant, Intune-managed devices from trusted named locations only, blocking all other access pending investigation completion.
If the sign-in originated from a bulletproof ASN or Tor exit node, create a named location block in Conditional Access for that IP range and add the specific IPs to the Microsoft Defender Threat Intelligence block list.
Search for OAuth applications the user may have consented to during the compromised session (AuditLogs | where OperationName == 'Consent to application') and revoke any suspicious app permissions immediately.

Evidence Collection

Export the complete AADSignInLogs for the user covering T-72h to T+24h relative to the first suspicious event, including all fields: IPAddress, Location, DeviceDetail, AuthenticationDetails, ConditionalAccessPolicies, RiskDetail.
Collect AuditLogs for the same window filtered to the user's ObjectId covering: password changes, MFA method changes, role assignments, group membership changes, OAuth consent events, and named location modifications.
If the compromised account has Exchange Online access, collect OfficeActivity records for MailItemsAccessed, Send, and FolderBind operations to determine whether the adversary read or exfiltrated email content.
Capture the DeviceDetail JSON from the suspicious successful sign-in (browser, OS, device ID) to fingerprint the adversary's access device for correlation across other potentially compromised accounts.
Pull CloudAppEvents for any file access or download activity in SharePoint, OneDrive, or Teams during the compromised session window. Note file names, sizes, and destination IPs for any download operations.

Escalation Criteria

! Escalate to Incident Response immediately if the compromised account holds any privileged Azure AD roles (Global Admin, Privileged Role Administrator, Security Administrator, Exchange Administrator) — blast radius is organizational.
! Escalate if evidence of email access or exfiltration is found (MailItemsAccessed events) involving HR, Finance, Legal, or Executive mailboxes, as this likely constitutes a data breach requiring legal and compliance notification.
! Escalate if the same source IP or user agent pattern is found in AADSignInLogs for multiple other accounts, indicating a coordinated credential stuffing campaign targeting the organization.
! Escalate if MFA re-registration or trusted device additions occurred under the compromised session, confirming the adversary has established durable access and is attempting to survive a password reset.
! Escalate if OfficeActivity shows the compromised account sent internal emails with attachments or links (potential internal spearphishing — T1534) during the suspicious session window.

Investigation Guide

Forensic Artifacts

> Azure AD Sign-in Logs (AADSignInLogs) — full authentication record including IP, user agent, device, MFA method, conditional access outcome, and risk score
> Azure AD Audit Logs (AuditLogs) — MFA method registration and deletion, password reset events, OAuth consent grants, role assignment changes
> OfficeActivity table — MailItemsAccessed, FolderBind, Send, FileDownloaded events linked to the compromised session
> Windows Security EventID 4624/4625/4648 — local and network authentication successes and failures on-premises with source IP and logon type
> Windows Security EventID 4776 — NTLM credential validation attempts against domain controllers, useful for identifying password spray patterns
> Conditional Access sign-in diagnostic reports — show which policies evaluated and whether enforcement gaps allowed the compromised session through
> Microsoft Entra ID Identity Protection RiskDetections — automated risk signals including leaked credentials, impossible travel, anonymous IP use, and password spray detections from Microsoft telemetry

Tuning Guidance

Start by establishing baselines: run the KQL credential stuffing query with FailureCount >= 20 for the first week to identify high-volume patterns, then tune down to 5. Add known corporate VPN egress IPs and branch office subnets to Azure AD Named Locations and exclude them from the SuspiciousASN detection. For impossible travel, configure the RiskDetections table through Identity Protection rather than rebuilding the logic — Microsoft's signal has lower false positive rates than time-based heuristics. Create watchlists in Microsoft Sentinel for legitimate shared accounts (service desks, shared mailboxes) and exclude them from CredentialStuffing detections. Suppress the legacy auth hunt for any service accounts explicitly exempted from the legacy auth Conditional Access policy. Correlate detections with Identity Protection RiskLevel before paging — low risk scores combined with high failure thresholds are often automation or misconfigured clients.

Hunting Queries

Hunts for accounts flagged by Azure AD Identity Protection as having leaked or sprayed credentials that also had recent successful authentications, indicating active exploitation of known-compromised credentials. Complements the main detection by using Microsoft's breach correlation telemetry rather than behavioral thresholds.

Hunting — KQL

kql

// Hunt: Accounts with successful login after credential exposure in breach databases
// Cross-references Identity Protection leaked credential detections with successful sign-ins
AADRiskyUsers
| where RiskDetail has_any ("leakedCredentials", "passwordSpray", "anonymizedIPAddress")
| where RiskState in ("atRisk", "confirmedCompromised")
| join kind=inner (
    AADSignInLogs
    | where TimeGenerated > ago(30d)
    | where ResultType == "0"
    | summarize LastSuccessfulLogin = max(TimeGenerated), LoginCount = count(),
        SuccessIPs = make_set(IPAddress, 10), Apps = make_set(AppDisplayName, 5)
        by UserPrincipalName
) on UserPrincipalName
| project UserPrincipalName, RiskDetail, RiskState, RiskLastUpdatedDateTime,
    LastSuccessfulLogin, LoginCount, SuccessIPs, Apps
| sort by RiskLastUpdatedDateTime desc

Hunting — SPL

spl

index=* sourcetype="WinEventLog:Security" EventCode=4625
| eval FailHour=strftime(_time, "%Y-%m-%d %H:00")
| stats dc(src_ip) AS UniqueSourceIPs, count AS FailCount
    by user, FailHour
| where UniqueSourceIPs > 20 AND FailCount > 100
| eval DetectionType="PasswordSprayCampaign"
| sort - FailCount

Hunts for OAuth application consent grants that occurred within 2 hours of a high-risk sign-in event, a pattern consistent with adversaries establishing persistent delegated access to mailboxes and files after initial account compromise. This is distinct from the main detection's authentication anomaly focus.

Hunting — KQL

kql

// Hunt: New OAuth application consents during high-risk sign-in sessions
// Adversaries often consent OAuth apps post-compromise to establish persistent access
let RiskySignIns = AADSignInLogs
| where TimeGenerated > ago(7d)
| where RiskLevelDuringSignIn in ("high", "medium")
| where ResultType == "0"
| project UserId = UserId, RiskySignInTime = TimeGenerated, IPAddress, Location;
AuditLogs
| where TimeGenerated > ago(7d)
| where OperationName == "Consent to application"
| extend UserId = tostring(InitiatedBy.user.id)
| join kind=inner RiskySignIns on UserId
| where TimeGenerated between (RiskySignInTime .. (RiskySignInTime + 2h))
| extend AppName = tostring(TargetResources[0].displayName),
    ConsentedScopes = tostring(TargetResources[0].modifiedProperties)
| project TimeGenerated, UserId, AppName, ConsentedScopes, RiskySignInTime, IPAddress, Location
| sort by TimeGenerated desc

Hunting — SPL

spl

index=* sourcetype="WinEventLog:Security" EventCode IN (4624, 4648)
    LogonType IN (3, 10)
| eval Hour=strftime(_time, "%Y-%m-%d %H")
| stats dc(src_ip) AS UniqueSourceIPs, values(src_ip) AS SourceIPs,
    count AS LogonCount, values(WorkstationName) AS Sources
    by user, Hour
| where UniqueSourceIPs >= 3 AND LogonCount >= 5
| eval SuspiciousLateralMovement=if(UniqueSourceIPs > 5, "High", "Medium")
| table user, Hour, UniqueSourceIPs, LogonCount, SourceIPs, Sources, SuspiciousLateralMovement
| sort - UniqueSourceIPs

Hunts for accounts successfully authenticating via legacy protocols (IMAP, POP3, SMTP AUTH, ActiveSync) that bypass MFA enforcement, a common technique used after account credential compromise to maintain persistent access even when the password is reset and MFA is enforced on modern auth flows.

Hunting — KQL

kql

// Hunt: Accounts authenticating with legacy protocols after MFA enforcement
// Adversaries use legacy auth protocols (SMTP AUTH, IMAP, POP3) that bypass MFA
AADSignInLogs
| where TimeGenerated > ago(14d)
| where ClientAppUsed in (
    "Exchange ActiveSync", "IMAP", "POP3", "SMTP", "Other clients",
    "Authenticated SMTP", "Autodiscover", "Exchange Online PowerShell",
    "Exchange Web Services", "MAPI Over HTTP"
  )
| where ResultType == "0"
| where AuthenticationRequirement == "singleFactorAuthentication"
| summarize
    LegacyAuthSuccesses = count(),
    UniqueIPs = dcount(IPAddress),
    IPList = make_set(IPAddress, 5),
    Protocols = make_set(ClientAppUsed, 5),
    FirstSeen = min(TimeGenerated),
    LastSeen = max(TimeGenerated)
    by UserPrincipalName
| where LegacyAuthSuccesses > 0
| sort by LegacyAuthSuccesses desc

Hunting — SPL

spl

index=* sourcetype="WinEventLog:Security" EventCode=4624 LogonType=8
| stats count AS NTLMBasicCount, dc(src_ip) AS UniqueIPs, values(src_ip) AS SourceIPs,
    min(_time) AS FirstSeen, max(_time) AS LastSeen
    by user, TargetDomainName
| where NTLMBasicCount > 3
| eval Note="NTLM LogonType 8 = NetworkCleartext, indicates legacy auth or basic auth bypass"
| sort - NTLMBasicCount

Atomic Red Team Tests

Test 1 Simulate credential stuffing authentication pattern using PowerShell against Azure AD

windows

Generates multiple failed authentication attempts followed by a successful login against Azure AD using the Microsoft Authentication Library, simulating the pattern produced by credential stuffing tools. Requires a test account with a known password. WARNING: Run only in a test tenant or with explicit SOC coordination.

Command

powershell

# Prerequisites: Install MSAL.PS module
Install-Module -Name MSAL.PS -Force -Scope CurrentUser

$TenantId = "YOUR_TENANT_ID"
$ClientId = "04b07795-8ddb-461a-bbee-02f9e1bf7b46"  # Microsoft Azure CLI (public client)
$TestUPN = "[email protected]"
$WrongPassword = "WrongPassword123!"
$CorrectPassword = "ActualTestPassword1!"

# Generate 6 failure events
1..6 | ForEach-Object {
    try {
        Get-MsalToken -TenantId $TenantId -ClientId $ClientId `
            -UserCredential (New-Object PSCredential($TestUPN, `
            (ConvertTo-SecureString $WrongPassword -AsPlainText -Force))) `
            -ErrorAction Stop
    } catch { Write-Host "Failure $_: $_" }
    Start-Sleep -Seconds 2
}

# Generate 1 success event
Get-MsalToken -TenantId $TenantId -ClientId $ClientId `
    -UserCredential (New-Object PSCredential($TestUPN, `
    (ConvertTo-SecureString $CorrectPassword -AsPlainText -Force)))

Write-Host "Test complete. Verify AADSignInLogs for $TestUPN shows 6 failures then 1 success."

Cleanup

powershell

Remove-Module MSAL.PS -Force

Expected Telemetry

AADSignInLogs will show 6 ResultType != 0 events followed by 1 ResultType == 0 event for the test UPN from the same source IP within a short time window. RiskState may update in AADRiskyUsers within 15-30 minutes.

Expected Detection

KQL CredentialStuffing signal should fire with FailureCount=6, SuccessCount=1, UniqueIPs=1, RiskScore=55. SPL query should produce a matching row for the test account.

Test 2 Simulate legacy protocol authentication bypass against Exchange Online (SMTP AUTH)

windows

Tests SMTP AUTH authentication against Exchange Online using a test account, simulating how adversaries use legacy protocols to bypass MFA and access compromised email accounts. Validates the legacy protocol hunting query.

Command

powershell

# Test SMTP AUTH authentication (simulates adversary using compromised creds via legacy protocol)
$SMTPServer = "smtp.office365.com"
$SMTPPort = 587
$TestEmail = "[email protected]"
$TestPassword = "ActualTestPassword1!"

$SMTP = New-Object System.Net.Mail.SmtpClient($SMTPServer, $SMTPPort)
$SMTP.EnableSsl = $true
$SMTP.Credentials = New-Object System.Net.NetworkCredential($TestEmail, $TestPassword)

try {
    # Authenticate without sending mail — just test credentials
    $SMTP.Send($TestEmail, $TestEmail, "[ATOMIC TEST] Legacy Auth Detection Validation",
        "This is an atomic test for T1586 legacy auth detection. Sent: $(Get-Date)")
    Write-Host "SMTP AUTH succeeded — check AADSignInLogs for ClientAppUsed=Authenticated SMTP"
} catch {
    Write-Host "SMTP AUTH test result: $_"
} finally {
    $SMTP.Dispose()
}

Cleanup

powershell

No cleanup required. Delete the test email from the mailbox if sent successfully.

Expected Telemetry

AADSignInLogs entry with ClientAppUsed='Authenticated SMTP', AuthenticationRequirement='singleFactorAuthentication', ResultType=0 for the test account. This event will NOT appear in modern auth logs, validating the legacy auth gap.

Expected Detection

KQL legacy protocol hunting query should return the test UPN with LegacyAuthSuccesses >= 1 and protocol 'Authenticated SMTP' in Protocols list.

Test 3 Simulate account compromise indicators via failed then successful Windows network logon from multiple sources

windows

Uses net use commands from different simulated source contexts to generate Windows Security Event IDs 4625 (failure) and 4624 (success) for a test account, validating the SPL credential stuffing detection on Windows domain infrastructure.

Command

powershell

# Run from a domain-joined Windows host as admin
# Replace TEST_DC with your domain controller hostname and TESTDOMAIN\testuser with a valid test account

$DC = "TEST_DC"
$TestAccount = "TESTDOMAIN\\testuser_atomic"
$WrongPass = "BadPassword999!"
$CorrectPass = "CorrectPassword1!"

# Generate failure events (EventID 4625)
Write-Host "Generating authentication failures..."
1..6 | ForEach-Object {
    $result = & cmdkey /add:$DC /user:$TestAccount /pass:$WrongPass 2>&1
    & net use \\$DC\ADMIN$ /user:$TestAccount $WrongPass 2>&1 | Out-Null
    & net use \\$DC\ADMIN$ /delete 2>&1 | Out-Null
    Start-Sleep -Milliseconds 500
}

# Generate success event (EventID 4624 Type 3)
Write-Host "Generating successful authentication..."
& net use \\$DC\ADMIN$ /user:$TestAccount $CorrectPass
Start-Sleep -Seconds 2
& net use \\$DC\ADMIN$ /delete

Write-Host "Atomic test complete. Check Security event log on $DC for EventID 4625 x6 and 4624 x1 for $TestAccount"

Cleanup

powershell

net use * /delete /yes
cmdkey /delete:TEST_DC

Expected Telemetry

Windows Security EventID 4625 (LogonType 3, SubStatus 0xC000006A = wrong password) six times followed by EventID 4624 (LogonType 3) once for the test account in the domain controller Security event log. Source workstation will be the executing host.

Expected Detection

SPL query should return a row for testuser_atomic with FailureCount=6, SuccessCount=1, UniqueIPs=1 (or more if run from multiple hosts), RiskScore=55, DetectionType=CredentialStuffingThenSuccess.

What is T1586 Compromise Accounts?

MITRE ATT&CK

Data Sources

Required Tables

False Positives

Data Sources

Required Sourcetypes

False Positives

Data Sources

Required Tables

False Positives

Data Sources

Required Tables

False Positives

Data Sources

Required Tables

False Positives

Data Sources

Required Tables

False Positives

Data Sources

Required Tables

False Positives

Sigma rule & cross-platform mapping

Platform-specific guides for T1586

Testing Methodology

Response Playbook

Triage

Containment

Evidence Collection

Escalation Criteria

Investigation Guide

Forensic Artifacts

Tuning Guidance

Hunting Queries

Atomic Red Team Tests

Command

Cleanup

Expected Telemetry

Expected Detection

Command

Cleanup

Expected Telemetry

Expected Detection

Command

Cleanup

Expected Telemetry

Expected Detection

Related Detections

Tactic Hub

Sub-techniques (3)

Related Techniques

Same Tactic: Resource Development

Popular Detections

Get new detections in your inbox