Which SIEM platforms have a T1078 detection rule?

df00tech provides T1078 (Valid 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 severity and confidence is the T1078 detection?

The T1078 detection is rated high severity with medium confidence.

What are common false positives for T1078?

Common false positives for T1078 include: Legitimate travel — users accessing resources from new countries or cities during business travel; VPN or proxy changes — users switching VPN exit nodes causing IP and apparent location changes; New device enrollment — first-time access from a newly provisioned corporate device triggers 'new IP' anomaly.

T1078

Valid Accounts

Q: What data sources are required to detect Valid Accounts (T1078)?

Detecting Valid Accounts requires the following data sources: Logon Session: Logon Session Creation, User Account: User Account Authentication, Azure Active Directory Sign-In Logs.

Initial Access Persistence Privilege Escalation Defense Evasion Last updated: April 13, 2026

Adversaries may obtain and abuse credentials of existing accounts as a means of gaining Initial Access, Persistence, Privilege Escalation, or Defense Evasion. Compromised credentials may be used to bypass access controls placed on various resources on systems within the network and may even be used for persistent access to remote systems and externally available services, such as VPNs, Outlook Web Access, network devices, and remote desktop. Compromised credentials may also grant an adversary increased privilege to specific systems or access to restricted areas of the network. Adversaries may choose not to use malware or tools in conjunction with the legitimate access those credentials provide to make it harder to detect their presence. In some cases, adversaries may abuse inactive accounts belonging to individuals who are no longer part of an organization.

What is T1078 Valid Accounts?

Valid Accounts (T1078) maps to the Initial Access and Persistence and Privilege Escalation and Defense Evasion tactics — the adversary is trying to get into your network in MITRE ATT&CK.

This page provides production-ready detection logic for Valid Accounts, covering the data sources and telemetry it touches: Logon Session: Logon Session Creation, User Account: User Account Authentication, Azure Active Directory Sign-In Logs. 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: Initial Access Persistence Privilege Escalation Defense Evasion
Technique: T1078 Valid Accounts
Canonical reference: https://attack.mitre.org/techniques/T1078/

Microsoft Sentinel / Defender

kusto

// Detect anomalous logon patterns indicative of compromised valid accounts
let LookbackDays = 14d;
let AnomalyWindow = 1d;
// Baseline: countries/cities seen per user in lookback window
let UserLocationBaseline = SigninLogs
| where TimeGenerated between (ago(LookbackDays) .. ago(AnomalyWindow))
| where ResultType == 0
| summarize BaselineLocations=make_set(Location), BaselineIPs=make_set(IPAddress), BaselineApps=make_set(AppDisplayName) by UserPrincipalName;
// Recent logons to compare against baseline
let RecentLogons = SigninLogs
| where TimeGenerated > ago(AnomalyWindow)
| where ResultType == 0
| project TimeGenerated, UserPrincipalName, IPAddress, Location, AppDisplayName,
         DeviceDetail, AuthenticationRequirement, ConditionalAccessStatus,
         RiskLevelDuringSignIn, RiskLevelAggregated, IsInteractive;
// Join and find anomalies
RecentLogons
| join kind=leftouter UserLocationBaseline on UserPrincipalName
| extend NewLocation = not(Location in (BaselineLocations))
| extend NewIP = not(IPAddress in (BaselineIPs))
| extend NewApp = not(AppDisplayName in (BaselineApps))
| extend AnomalyScore = toint(NewLocation) + toint(NewIP) + toint(NewApp)
         + toint(RiskLevelDuringSignIn in ("high", "medium"))
         + toint(ConditionalAccessStatus == "notApplied")
| where AnomalyScore >= 2 or RiskLevelDuringSignIn == "high"
| project TimeGenerated, UserPrincipalName, IPAddress, Location, AppDisplayName,
         NewLocation, NewIP, NewApp, AnomalyScore,
         RiskLevelDuringSignIn, RiskLevelAggregated,
         ConditionalAccessStatus, AuthenticationRequirement,
         IsInteractive, DeviceDetail
| sort by AnomalyScore desc, TimeGenerated desc

Detects anomalous sign-in patterns in Azure AD / Entra ID that may indicate valid account abuse. Compares recent logons against a 14-day baseline per user to identify new geolocations, new IP addresses, new application access, elevated risk scores, and missing Conditional Access enforcement. An anomaly score of 2+ triggers the alert. Covers Initial Access via external services and Persistence via re-authentication.

high severity medium confidence

Data Sources

Logon Session: Logon Session Creation User Account: User Account Authentication Azure Active Directory Sign-In Logs

Required Tables

SigninLogs

False Positives

Legitimate travel — users accessing resources from new countries or cities during business travel
VPN or proxy changes — users switching VPN exit nodes causing IP and apparent location changes
New device enrollment — first-time access from a newly provisioned corporate device triggers 'new IP' anomaly
After-hours legitimate access — on-call engineers or executives working outside normal hours from home networks
Conditional Access policy rollout periods — new CA policies may temporarily show as 'notApplied' during staged deployment

Splunk

spl

index=wineventlog sourcetype="WinEventLog:Security"
  (EventCode=4624 OR EventCode=4625 OR EventCode=4648 OR EventCode=4672)
| eval LogonType=case(
    LogonType=="2", "Interactive",
    LogonType=="3", "Network",
    LogonType=="4", "Batch",
    LogonType=="5", "Service",
    LogonType=="7", "Unlock",
    LogonType=="8", "NetworkCleartext",
    LogonType=="9", "NewCredentials",
    LogonType=="10", "RemoteInteractive",
    LogonType=="11", "CachedInteractive",
    true(), "Unknown_"+LogonType)
| eval IsPrivileged=if(EventCode=="4672", 1, 0)
| eval IsFailed=if(EventCode=="4625", 1, 0)
| eval IsNewCredentials=if(EventCode=="4648", 1, 0)
| eval SuspiciousLogonType=if(LogonType IN ("NetworkCleartext", "NewCredentials"), 1, 0)
| eval IsAdminAccount=if(match(lower(TargetUserName), "(admin|svc|service|sa_|_svc|robot|automation)"), 1, 0)
| stats count as TotalEvents,
        sum(IsFailed) as FailedLogons,
        sum(IsPrivileged) as PrivilegedLogons,
        sum(IsNewCredentials) as NewCredentialUse,
        sum(SuspiciousLogonType) as SuspiciousLogonTypes,
        values(LogonType) as LogonTypes,
        values(IpAddress) as SourceIPs,
        dc(IpAddress) as UniqueSourceIPs,
        values(WorkstationName) as Workstations,
        dc(WorkstationName) as UniqueWorkstations
  by TargetUserName, TargetDomainName, _time span=1h
| eval RiskScore=SuspiciousLogonTypes*2 + if(FailedLogons>5 AND PrivilegedLogons>0, 3, 0)
               + if(UniqueSourceIPs>3, 2, 0) + if(UniqueWorkstations>4, 2, 0)
               + NewCredentialUse
| where RiskScore >= 3
| table _time, TargetUserName, TargetDomainName, TotalEvents, FailedLogons,
        PrivilegedLogons, NewCredentialUse, UniqueSourceIPs, SourceIPs,
        UniqueWorkstations, LogonTypes, RiskScore
| sort - RiskScore

Detects suspicious account usage patterns using Windows Security Event logs. Aggregates logon events (4624 successful, 4625 failed, 4648 explicit credential use, 4672 special privilege logon) per user per hour and computes a risk score. High risk scores emerge from: suspicious logon types (cleartext/new credentials), failed logons preceding privilege use, multiple source IPs, and widespread workstation access — patterns consistent with credential abuse by APT41, FIN8, Volt Typhoon, and Scattered Spider.

high severity medium confidence

Data Sources

Logon Session: Logon Session Creation User Account: User Account Authentication Windows Security Event Log

Required Sourcetypes

WinEventLog:Security

False Positives

Service accounts performing scheduled tasks across multiple hosts — these legitimately generate high-volume network logon events from multiple workstations
IT administrators managing servers via RDP or PSRemoting — legitimate multi-workstation remote interactive logons from admin accounts
Password synchronization tools and SSO solutions causing 4648 (explicit credential) events in bulk during sync cycles
Backup agents and monitoring software authenticating to multiple endpoints — creates legitimate multi-source-IP logon patterns
Domain controller replication events generating multiple 4624 type 3 (network) logons between DCs

Elastic Security (EQL)

eql

sequence by winlog.event_data.TargetUserName with maxspan=1h
  [authentication where
    event.code == "4625" and
    not winlog.event_data.TargetUserName in~ ("system", "anonymous logon", "-", "local service", "network service") and
    not winlog.event_data.TargetUserName like "*$"
  ] with runs=5
  [authentication where
    event.code in ("4624", "4648", "4672") and
    not winlog.event_data.TargetUserName in~ ("system", "anonymous logon", "-", "local service", "network service") and
    (
      winlog.event_data.LogonType in ("8", "9", "10") or
      event.code == "4672" or
      event.code == "4648"
    )
  ]

Detects T1078 Valid Accounts abuse using an EQL sequence: 5 or more failed authentication events (Event ID 4625) followed within one hour by a successful logon bearing suspicious characteristics — privileged session creation (4672), explicit alternate credential use (4648), or a high-risk logon type such as NetworkCleartext (type 8), NewCredentials (type 9), or RemoteInteractive (type 10). Sequence correlation eliminates the high false-positive rate of pure threshold approaches by requiring the failure-then-success pattern rather than counting failures alone. Machine accounts (ending in $) and built-in system identities are suppressed.

high severity high confidence

Data Sources

Windows Security Event Log via Winlogbeat Elastic Agent Endpoint Integration Windows Event Forwarding (WEF) to Elastic

Required Tables

authentication (ECS event.category) winlog.event_data

False Positives

Legitimate users who repeatedly mistype a new password after a forced reset and then successfully authenticate from an RDP session or remote access gateway, satisfying the failure-then-success-with-RemoteInteractive pattern
IT administrators who run scripted credential validation tests (e.g., Test-ADAuthentication loops) followed by an intentional successful logon to confirm account functionality after a password change
Service account password rotation workflows where the old credential is attempted several times by a lagging process before the new credential takes effect, followed by a successful logon of type NewCredentials from the updated service

IBM QRadar (AQL)

sql

SELECT
  username AS target_user,
  DATEFORMAT(starttime, 'yyyy-MM-dd HH:00:00') AS event_hour,
  COUNT(*) AS total_events,
  COUNT(DISTINCT sourceip) AS unique_source_ips,
  SUM(CASE WHEN eventid = 4625 THEN eventcount ELSE 0 END) AS failed_logons,
  SUM(CASE WHEN eventid = 4672 THEN eventcount ELSE 0 END) AS privileged_logons,
  SUM(CASE WHEN eventid = 4648 THEN eventcount ELSE 0 END) AS new_credential_use,
  SUM(CASE WHEN eventid = 4624 THEN eventcount ELSE 0 END) AS successful_logons,
  MIN(sourceip) AS sample_source_ip
FROM events
WHERE
  LOGSOURCETYPENAME(devicetype) = 'Microsoft Windows Security Event Log'
  AND eventid IN (4624, 4625, 4648, 4672)
  AND username NOT IN ('SYSTEM', 'ANONYMOUS LOGON', '-', 'LOCAL SERVICE', 'NETWORK SERVICE')
  AND username NOT LIKE '%$'
  AND starttime > NOW() - 3600000
GROUP BY
  username,
  DATEFORMAT(starttime, 'yyyy-MM-dd HH:00:00')
HAVING
  failed_logons > 5
  OR (unique_source_ips > 3 AND successful_logons > 0)
  OR (new_credential_use > 0 AND privileged_logons > 0)
ORDER BY total_events DESC
LAST 1 HOURS

AQL query that aggregates Windows Security authentication events (4624 successful logon, 4625 failed logon, 4648 logon with explicit credentials, 4672 special privilege assignment) per user per hour across all Windows Security Event Log sources. Flags accounts meeting any of three risk conditions: more than 5 failed logons, successful logons arriving from more than 3 distinct source IPs within the hour, or the co-occurrence of explicit credential use and privileged session creation. Machine accounts and known system identities are excluded. Mirrors the risk-scoring logic of the SPL detection adapted to QRadar's AQL aggregation model.

high severity medium confidence

Data Sources

Microsoft Windows Security Event Log (QRadar WinCollect) Microsoft Windows Security Event Log DSM IBM QRadar Log Source Extension for Windows

Required Tables

events

False Positives

System administrators who authenticate to many managed workstations from a single jump host generate multiple 4624 events with the same sourceip, but automated inventory or patch management tools may pull credentials from several IPs, inflating unique_source_ips past the threshold during maintenance windows
Ansible, SCCM, or similar configuration management platforms that authenticate as a service account across dozens of endpoints in parallel within a single hour will reliably exceed the unique_source_ips threshold without any malicious activity
Helpdesk workflows where staff use RunAs (generating 4648) to launch an elevated tool and then perform privileged operations (generating 4672) during a support ticket are a common and entirely legitimate co-occurrence of new_credential_use and privileged_logons

Sumo Logic CSE

sql

_sourceCategory=*windows* OR _sourceCategory=*WinEventLog* OR _sourceCategory=*Security*
| where EventCode in ("4624", "4625", "4648", "4672")
| parse regex field=Message "Account Name:\\s+(?<TargetUserName>\\S+)" nodrop
| parse regex field=Message "Account Domain:\\s+(?<TargetDomainName>\\S+)" nodrop
| parse regex field=Message "Logon Type:\\s+(?<LogonType>\\d+)" nodrop
| parse regex field=Message "Source Network Address:\\s+(?<SourceIP>[^\\s\\r\\n]+)" nodrop
| where TargetUserName != "SYSTEM" and TargetUserName != "ANONYMOUS LOGON" and TargetUserName != "-"
| where !(TargetUserName matches /.*\$$/) 
| where SourceIP != "-" and !(SourceIP matches /^$/) 
| eval IsFailed = if(EventCode == "4625", 1, 0)
| eval IsPrivileged = if(EventCode == "4672", 1, 0)
| eval IsNewCreds = if(EventCode == "4648", 1, 0)
| eval IsSuspiciousLogon = if(LogonType in ("8", "9"), 1, 0)
| eval IsAdminAccount = if(TargetUserName matches /(?i)(admin|svc|service|sa_|_svc|robot|automation)/, 1, 0)
| timeslice 1h
| stats sum(IsFailed) as FailedLogons,
        sum(IsPrivileged) as PrivilegedLogons,
        sum(IsNewCreds) as NewCredentialUse,
        sum(IsSuspiciousLogon) as SuspiciousLogons,
        sum(IsAdminAccount) as AdminAccountEvents,
        count_distinct(SourceIP) as UniqueSourceIPs,
        count as TotalEvents
  by _timeslice, TargetUserName, TargetDomainName
| eval RiskScore = (SuspiciousLogons * 2)
                 + if(FailedLogons > 5 and PrivilegedLogons > 0, 3, 0)
                 + if(UniqueSourceIPs > 3, 2, 0)
                 + NewCredentialUse
                 + (AdminAccountEvents > 0 ? 1 : 0)
| where RiskScore >= 3
| sort by RiskScore desc

Parses Windows Security authentication events ingested by a Sumo Logic Installed Collector, extracts logon metadata from the raw Message field using regex, and computes a per-user hourly risk score equivalent to the Splunk detection. Weights suspicious logon types (NetworkCleartext type 8, NewCredentials type 9), the combination of failed-then-privileged access, multiple source IPs, explicit credential re-use, and admin-pattern account names. Machine accounts (names ending in $) and events with null source IPs are excluded to reduce noise.

high severity medium confidence

Data Sources

Windows Security Event Log via Sumo Logic Installed Collector (Windows Event Log Source) Sumo Logic Cloud Syslog for Windows Event Forwarding

Required Tables

_sourceCategory (WinEventLog/Security or equivalent)

False Positives

Users connecting through Citrix Virtual Apps or a terminal services gateway may authenticate from multiple backend proxy IPs within a single hour, inflating UniqueSourceIPs past the threshold without any credential compromise
Robotic Process Automation (RPA) tools that use NetworkCleartext (type 8) logons against legacy web applications or mainframe connectors as part of scheduled automation workflows will consistently score as suspicious logon types
Shared administrator accounts used simultaneously by multiple helpdesk analysts from their individual workstations generate high UniqueSourceIPs counts and may also trigger admin-account pattern matching even during fully authorized operations

Google Chronicle / SecOps

yaral

rule t1078_valid_accounts_failed_then_privileged_logon {
  meta:
    author = "Detection Engineering"
    description = "Detects T1078 Valid Accounts abuse: 5+ failed authentication events followed within one hour by a successful logon with elevated privileges or suspicious authentication mechanism"
    mitre_attack_tactic = "Initial Access, Persistence, Privilege Escalation, Defense Evasion"
    mitre_attack_technique = "T1078"
    mitre_attack_url = "https://attack.mitre.org/techniques/T1078/"
    severity = "HIGH"
    confidence = "MEDIUM"
    version = "1.0"

  events:
    $fail.metadata.event_type = "USER_LOGIN_FAIL"
    $fail.metadata.vendor_name = "Microsoft"
    $fail.target.user.userid != ""
    not re.regex($fail.target.user.userid, `(?i)^(SYSTEM|ANONYMOUS LOGON|LOCAL SERVICE|NETWORK SERVICE)$`)
    not re.regex($fail.target.user.userid, `\$$`)
    $user = $fail.target.user.userid

    $success.metadata.event_type = "USER_LOGIN"
    $success.target.user.userid = $user
    (
      $success.extensions.auth.auth_details = "NetworkCleartext" or
      $success.extensions.auth.auth_details = "NewCredentials" or
      $success.extensions.auth.auth_details = "RemoteInteractive" or
      $success.extensions.auth.mechanism = "REMOTE" or
      $success.security_result.severity_details = "HIGH"
    )

  match:
    $user over 1h

  condition:
    #fail > 5 and #success >= 1
}

Chronicle YARA-L 2.0 rule that correlates USER_LOGIN_FAIL events against USER_LOGIN events in the UDM (Unified Data Model) for the same user identity within a rolling one-hour window. Alerts when more than 5 authentication failures precede at least one successful logon exhibiting a suspicious characteristic: NetworkCleartext or NewCredentials auth details (UDM extension fields mapped from Windows logon types 8/9), RemoteInteractive session, a REMOTE auth mechanism, or a HIGH-severity security result. Machine accounts and system identities are excluded via YARA-L regex. The `#fail` and `#success` counters in the condition block count matched event instances within the match window.

high severity high confidence

Data Sources

Google Chronicle UDM Microsoft Windows Security Events (via Chronicle Windows Sensor or Forwarder) Azure AD Sign-in Logs (via Chronicle Azure AD ingestion)

Required Tables

UDM Events — event_type: USER_LOGIN, USER_LOGIN_FAIL

False Positives

Users who repeatedly mistype a complex new password after a forced reset before successfully authenticating via an RDP gateway will satisfy the 5-failure threshold and match RemoteInteractive in the success event
Automated testing or synthetic monitoring agents that deliberately attempt credential validation (expecting failures) before performing a confirmation successful logon as part of identity health checks
Azure AD B2B guest account federation flows where the initial authentication attempts fail against the home tenant before succeeding through an external IdP, generating failure UDM events prior to the successful federated logon

CrowdStrike LogScale (CQL)

cql

// T1078 - Valid Accounts: Anomalous authentication risk scoring via Falcon telemetry
#event_simpleName in ("UserLogon", "UserLogonFailed2", "UserLogonV2")
| IsFailure := if(#event_simpleName = "UserLogonFailed2", "true", "false")
| groupBy([UserName, UserSid], function=[
    count(as=TotalEvents),
    count(filter={IsFailure = "true"}, as=FailedLogons),
    count(filter={IsFailure = "false"}, as=SuccessfulLogons),
    count(distinct=RemoteAddressIP4, as=UniqueSourceIPs),
    count(distinct=ComputerName, as=UniqueHosts),
    collect(RemoteAddressIP4, limit=10, as=SourceIPList),
    collect(ComputerName, limit=10, as=HostList)
  ], limit=10000)
| FailedLogons := toInt(FailedLogons)
| SuccessfulLogons := toInt(SuccessfulLogons)
| UniqueSourceIPs := toInt(UniqueSourceIPs)
| UniqueHosts := toInt(UniqueHosts)
| RiskScore := if(FailedLogons > 5 and SuccessfulLogons > 0, 3, 0)
             + if(UniqueSourceIPs > 3, 2, 0)
             + if(UniqueHosts > 4, 2, 0)
| where RiskScore >= 3
| where UserName != "" and UserName != "-"
| sort(RiskScore, order=desc, limit=100)

LogScale (CQL) query targeting CrowdStrike Falcon authentication telemetry events. Aggregates UserLogon (successful) and UserLogonFailed2 (failed) events per user identity (UserName and UserSid) and computes a risk score equivalent to the SPL detection: 3 points for 5+ failures followed by at least one success, 2 points for authentication spread across more than 3 distinct source IPs, and 2 points for more than 4 unique target hosts. Accounts with a combined risk score of 3 or higher are surfaced. SourceIPList and HostList are collected for analyst triage. Empty or dash usernames are filtered to remove noise from unauthenticated events.

high severity medium confidence

Data Sources

CrowdStrike Falcon Endpoint Activity Monitoring (EAM) CrowdStrike Falcon Identity Protection CrowdStrike Falcon Data Replicator (FDR)

Required Tables

#event_simpleName: UserLogon, UserLogonFailed2, UserLogonV2

False Positives

Falcon sensor deployment or mass update events generate synthetic logon telemetry across large numbers of hosts simultaneously, potentially inflating UniqueHosts counts for system or installer accounts beyond the detection threshold
Users connecting to cloud workloads through a cloud access security broker (CASB) or identity proxy that routes authentication through multiple egress IPs within a single session will exceed the UniqueSourceIPs threshold without any malicious activity
DevOps pipelines that authenticate a shared service account against multiple ephemeral build agents, Kubernetes nodes, or cloud VM instances during CI/CD runs will consistently exceed both the UniqueHosts and SuccessfulLogons thresholds as normal pipeline behavior

Sigma rule & cross-platform mapping

The detection logic for Valid Accounts (T1078) 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 T1078 Sigma rules on detection.fyi

Platform-specific guides for T1078

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 (8)

Testing Methodology

Validate this detection against 5 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 Compromised Account Remote Logon (Windows)
Expected signal: Security Event ID 4648 on source host (explicit credential logon with alternate credentials). Security Event ID 4624 LogonType=3 (network) on target host. Sysmon Event ID 3 (network connection) from cmd.exe to TARGET_HOST:445. Security Event ID 4672 if USERNAME has special privileges.
Test 2Simulate Service Account Lateral Movement via WMI
Expected signal: Security Event ID 4648 on initiating host. Security Event ID 4624 LogonType=3 on TARGET_HOST. Security Event ID 4688 (or Sysmon Event ID 1) showing WmiPrvSE.exe spawning cmd.exe on TARGET_HOST. Sysmon Event ID 3 showing DCOM/WMI network traffic to TARGET_HOST:135.
Test 3Simulate Dormant Account Reactivation (Local)
Expected signal: Security Event ID 4720 (account created). Security Event ID 4725 (account disabled). Security Event ID 4722 (account enabled — key indicator of reactivation). Security Event ID 4624 LogonType=2 (interactive) for df00tech_dormant. Audit event for account enabling action.
Test 4Simulate Cloud Account Compromise via Azure CLI
Expected signal: Azure AD SigninLogs entry with UserPrincipalName=compromised_user, AppDisplayName='Microsoft Azure CLI', ClientAppUsed='Other clients', AuthenticationRequirement='singleFactorAuthentication' (if no MFA). Azure Audit Log entries for resource enumeration. Entra ID Protection may generate a risk detection if login is from an unexpected location.
Test 5Test Impossible Travel Detection Trigger
Expected signal: Two SigninLogs entries for [email protected]: first from US IP, second from EU IP approximately 2 minutes later. Entra ID Protection should generate an 'Impossible Travel' risk detection. Both entries appear in the 24h window, different Location fields.

Response Playbook

Triage

Retrieve the full sign-in history for the account over the past 30 days — look for the first anomalous logon timestamp and what changed (new IP, new ASN, new country, new device fingerprint)
Check whether the account is a human user or service account — service accounts should have fixed source IPs and hosts; any deviation is high-confidence malicious
Identify the authentication method used — password-only auth on an MFA-enrolled account without an MFA event suggests MFA bypass (SIM swap, OTP phishing, adversary-in-the-middle)
Cross-reference the source IP against threat intel feeds — check VirusTotal, Shodan, or AbuseIPDB for the IP/ASN; residential proxy infrastructure and VPN exit nodes are common for credential abuse
Determine geographic plausibility — if the user logged in from New York 30 minutes before logging in from Singapore, the second login is impossible travel and high-confidence compromise
Review what the account accessed after the anomalous logon — did it access sensitive SharePoint/OneDrive, email, admin portals, or begin lateral movement via RDP/SMB?
Check if the account has recent MFA registration changes, password resets, or new app authorizations — adversaries often register new MFA devices or OAuth apps to maintain persistence after initial access

Containment

Immediately revoke all active sessions and refresh tokens for the compromised account: in Entra ID use 'Revoke Sign-In Sessions' from the user blade, or run: Revoke-AzureADUserAllRefreshToken -ObjectId <user-object-id>
Force password reset and require re-enrollment of MFA factors — specifically remove any MFA devices registered during or after the suspicious logon window
If on-premises AD: reset the Kerberos ticket-granting ticket by resetting the account password twice and running 'klist purge' on affected endpoints
Disable the account temporarily if immediate password reset is not operationally feasible, then coordinate with the user out-of-band (phone/in-person) for credential restoration
Block the identified threat actor IP(s)/ASN at the perimeter firewall, Conditional Access named locations, and email gateway
If lateral movement is detected: isolate affected endpoints using EDR network containment, and rotate credentials for any service accounts the compromised user could access
Audit and revoke any OAuth application consents granted during the suspicious session window

Evidence Collection

Azure AD / Entra ID Sign-In Logs (retention: 30 days default) — export to Log Analytics or Storage Account immediately if within window; include non-interactive sign-ins which are often missed
Azure AD Audit Logs — capture any MFA registration changes, password resets, role assignments, or OAuth consent grants made during the suspicious window
Windows Security Event ID 4624/4625/4648/4672 from domain controllers and affected endpoints — extract with wevtutil: wevtutil qe Security /q:"*[System[(EventID=4624 or EventID=4625) and TimeCreated[@SystemTime>='2026-03-14T00:00:00']]]"
VPN/remote access gateway logs — source IPs, connection duration, and transferred data volume during the suspicious period
Email access logs (Exchange/M365) — MailItemsAccessed audit record shows which emails were read; run: Search-UnifiedAuditLog -Operations MailItemsAccessed -UserIds <upn> -StartDate <date> -EndDate <date>
SharePoint/OneDrive access logs — FileAccessed, FileDownloaded events in the Unified Audit Log for any mass download during the suspicious window
Endpoint process creation and network events from the workstation(s) involved in the suspicious logon (Sysmon Event ID 1 and 3)
UEBA/Identity Protection risk detections export from Entra ID Protection — these may contain pre-existing risk signals that predated the alert

Escalation Criteria

! Confirmed impossible travel — two geographically separated successful logons within a timeframe that is physically impossible
! MFA bypass evidence — successful authentication without a corresponding MFA event for an MFA-enrolled account
! Privileged account compromise — any Domain Admin, Global Admin, or high-privilege service account showing anomalous access patterns
! Evidence of email exfiltration — MailItemsAccessed events for large volumes of sensitive email, or inbox rules forwarding to external addresses created post-compromise
! Lateral movement detected — the compromised account authenticating to additional hosts, using WMI, PsExec, RDP, or SMB after the initial anomalous logon
! Persistence mechanism established — new MFA device registered, OAuth app authorized, scheduled task or service created using the compromised account
! Multiple accounts compromised simultaneously — same source IP/ASN with anomalous logons across several accounts suggests bulk credential stuffing or a broader breach

Investigation Guide

Forensic Artifacts

> Windows Event Log: Security — Event 4624 (successful logon) with LogonType, Source IP, AuthPackage; Event 4625 (failed logon); Event 4648 (explicit credential use); Event 4672 (special privilege assigned)
> Windows Event Log: Security — Event 4768/4769 (Kerberos TGT/TGS requests) at domain controllers — reveals ticket-granting activity for the compromised account
> Windows Event Log: Security — Event 4776 (NTLM authentication) at domain controllers — source workstation and account for NTLM-based access
> Registry: HKLM\SYSTEM\CurrentControlSet\Control\Lsa — CachedLogonsCount, LmCompatibilityLevel affect authentication artifacts
> Registry: HKCU\Software\Microsoft\Terminal Server Client\Servers — cached RDP server entries indicating lateral movement destinations
> File System: C:\Users\<username>\AppData\Local\Microsoft\Credentials\ — DPAPI-protected credential blobs
> File System: C:\Windows\System32\winevt\Logs\Security.evtx — primary authentication event log (export before rotation)
> Azure AD: Sign-In Logs, Audit Logs, Risk Detections in Entra ID Protection (accessible via Azure Portal or Microsoft Graph API)
> Memory: LSASS process memory contains active Kerberos tickets and NTLM hashes for logged-on users — volatile, capture immediately if endpoint is live
> Network: NetFlow/firewall logs showing source IP, destination, protocol, and data volume for the suspicious session window

Tuning Guidance

Valid account detections require careful baseline establishment to avoid alert fatigue. Begin with a 30-day baseline of normal user behavior before enabling automated alerting. Key tuning steps: (1) Build an allowlist of known VPN exit node IP ranges and corporate proxy infrastructure — these create legitimate IP diversity. (2) Exclude service accounts from human-behavior anomaly rules and instead create dedicated rules for service account deviation (service accounts should have fixed source IPs, logon types, and target systems). (3) For MFA-enrolled accounts, add MFA success/failure as a required field — password-only auth on MFA accounts is almost always suspicious. (4) Use Entra ID Identity Protection risk scores as a pre-filter — risk scores of 'medium' or 'high' significantly reduce false positives. (5) Tune the dormancy threshold to match your organization's offboarding processes — if accounts are routinely disabled within 14 days of termination, a 30-day dormancy threshold may be appropriate. (6) For on-premises environments, create separate rules for interactive (Type 2, 10) vs. network (Type 3) logons — bulk Type 3 logons from service accounts are normal; bulk Type 10 (RDP) from non-admin accounts is suspicious. (7) Integrate with HR/ITSM systems to automatically exclude accounts with active travel requests or contractor engagements in new geographies.

Hunting Queries

Hunt for accounts authenticating from 3 or more distinct countries within a 24-hour window. This pattern indicates either account sharing (policy violation), credential compromise with active threat actor access, or legitimate global travel that warrants verification. APT groups like Scattered Spider are known to use residential proxies that appear as different country origins.

Hunting — KQL

kql

// Hunt for accounts logging in from multiple countries within 24h (impossible travel)
let TimeWindow = 24h;
SigninLogs
| where TimeGenerated > ago(7d)
| where ResultType == 0
| summarize Countries=make_set(Location), IPs=make_set(IPAddress), LogonCount=count(),
           FirstSeen=min(TimeGenerated), LastSeen=max(TimeGenerated)
  by UserPrincipalName, bin(TimeGenerated, TimeWindow)
| extend CountryCount=array_length(Countries)
| where CountryCount >= 3
| project-away TimeGenerated
| sort by CountryCount desc

Hunting — SPL

spl

index=o365 sourcetype="o365:management:activity" Operation="UserLoggedIn" ResultStatus="Succeeded"
| iplocation ClientIP
| stats dc(Country) as CountryCount, values(Country) as Countries, values(ClientIP) as IPs,
        count as LogonCount, earliest(_time) as FirstSeen, latest(_time) as LastSeen
  by UserId, span=24h
| where CountryCount >= 3
| sort - CountryCount

Hunt for accounts dormant for 90+ days that have suddenly become active. Adversaries frequently target inactive accounts of former employees or service accounts as they are less likely to have password changes, active MFA, or monitoring. This pattern is consistent with CISA-documented techniques used by groups targeting critical infrastructure.

Hunting — KQL

kql

// Hunt for dormant accounts suddenly becoming active after 90+ days of inactivity
let DormancyThreshold = 90d;
let RecentWindow = 7d;
let DormantAccounts = SigninLogs
| where TimeGenerated between (ago(365d) .. ago(DormancyThreshold))
| where ResultType == 0
| summarize LastActiveDate=max(TimeGenerated) by UserPrincipalName;
let RecentLogons = SigninLogs
| where TimeGenerated > ago(RecentWindow)
| where ResultType == 0
| summarize RecentLogonCount=count(), RecentIPs=make_set(IPAddress), RecentApps=make_set(AppDisplayName)
  by UserPrincipalName, RecentLogonDate=bin(TimeGenerated, 1d);
DormantAccounts
| join kind=inner RecentLogons on UserPrincipalName
| extend DaysDormant = datetime_diff('day', RecentLogonDate, LastActiveDate)
| where DaysDormant >= DormancyThreshold
| project UserPrincipalName, LastActiveDate, RecentLogonDate, DaysDormant,
         RecentLogonCount, RecentIPs, RecentApps
| sort by DaysDormant desc

Hunting — SPL

spl

index=wineventlog sourcetype="WinEventLog:Security" EventCode=4624
| bucket span=1d _time
| stats latest(_time) as LastLogon by TargetUserName
| eval DaysSinceLastLogon=round((now()-LastLogon)/86400, 0)
| where DaysSinceLastLogon < 7
| join type=left TargetUserName
  [search index=wineventlog sourcetype="WinEventLog:Security" EventCode=4624 earliest=-365d latest=-90d
   | stats latest(_time) as PreviousLogon by TargetUserName
   | eval DaysDormant=round((now()-PreviousLogon)/86400, 0)
   | where DaysDormant >= 90]
| where isnotnull(PreviousLogon)
| table TargetUserName, LastLogon, PreviousLogon, DaysDormant
| sort - DaysDormant

Hunt for accounts with concurrent or near-concurrent sessions from multiple distinct IP addresses within a 30-minute window. Legitimate users rarely authenticate from 3+ different IPs within 30 minutes. This pattern may indicate active credential sharing by a threat actor across multiple infrastructure nodes, or a credential-sharing botnet performing simultaneous actions with stolen credentials.

Hunting — KQL

kql

// Hunt for accounts used simultaneously from multiple distinct IP address ranges (concurrent sessions)
let ConcurrentWindow = 30m;
SigninLogs
| where TimeGenerated > ago(7d)
| where ResultType == 0
| summarize Sessions=make_list(pack('time', TimeGenerated, 'ip', IPAddress, 'app', AppDisplayName, 'location', Location))
  by UserPrincipalName
| mv-expand Session=Sessions
| extend SessionTime=todatetime(Session.time), SessionIP=tostring(Session.ip)
| order by UserPrincipalName, SessionTime asc
| serialize
| extend PrevTime=prev(SessionTime), PrevIP=prev(IPAddress), PrevUser=prev(UserPrincipalName)
| where UserPrincipalName == PrevUser
| extend TimeDiff=datetime_diff('minute', SessionTime, PrevTime)
| where TimeDiff <= toint(ConcurrentWindow / 1m) and SessionIP != PrevIP
| project UserPrincipalName, SessionTime, SessionIP, PrevTime, PrevIP, TimeDiff
| sort by TimeDiff asc

Hunting — SPL

spl

index=wineventlog sourcetype="WinEventLog:Security" EventCode=4624 LogonType IN ("3", "10")
| stats list(_time) as LogonTimes, list(IpAddress) as IpAddresses, dc(IpAddress) as UniqueIPs
  by TargetUserName span=30m
| where UniqueIPs >= 3
| mvexpand LogonTimes
| mvexpand IpAddresses
| stats values(IpAddresses) as IPs, count as Sessions by TargetUserName, UniqueIPs
| sort - UniqueIPs

Atomic Red Team Tests

Test 1 Simulate Compromised Account Remote Logon (Windows)

windows

Uses stored credentials to perform a network logon to a remote system, simulating an adversary using compromised credentials to access internal resources. This generates Event ID 4648 (explicit credential use) on the source and 4624 LogonType 3 on the target. Replace TARGET_HOST, USERNAME, and DOMAIN with test environment values.

Command

powershell

cmdkey /add:TARGET_HOST /user:DOMAIN\USERNAME /pass:Password123!
net use \\TARGET_HOST\IPC$ /user:DOMAIN\USERNAME Password123!
net use \\TARGET_HOST\IPC$ /delete

Cleanup

powershell

cmdkey /delete:TARGET_HOST

Expected Telemetry

Security Event ID 4648 on source host (explicit credential logon with alternate credentials). Security Event ID 4624 LogonType=3 (network) on target host. Sysmon Event ID 3 (network connection) from cmd.exe to TARGET_HOST:445. Security Event ID 4672 if USERNAME has special privileges.

Expected Detection

SPL rule triggers on 4648 + 4624 combination with UniqueSourceIPs > 1 within the hour window. KQL anomaly rule flags new IP/workstation combination for USERNAME if not seen in 14-day baseline.

Test 2 Simulate Service Account Lateral Movement via WMI

windows

Uses WMI with explicit credentials to execute a command on a remote host, mimicking APT41 and FIN8 lateral movement techniques where compromised service account credentials are used for remote code execution. Generates Event 4648 and 4624 LogonType 3, plus WMI activity.

Command

powershell

wmic /node:TARGET_HOST /user:DOMAIN\svc_account /password:ServicePass1! process call create "cmd.exe /c whoami > C:\Windows\Temp\wmi_test.txt"

Cleanup

powershell

wmic /node:TARGET_HOST /user:DOMAIN\svc_account /password:ServicePass1! process call create "cmd.exe /c del C:\Windows\Temp\wmi_test.txt"

Expected Telemetry

Security Event ID 4648 on initiating host. Security Event ID 4624 LogonType=3 on TARGET_HOST. Security Event ID 4688 (or Sysmon Event ID 1) showing WmiPrvSE.exe spawning cmd.exe on TARGET_HOST. Sysmon Event ID 3 showing DCOM/WMI network traffic to TARGET_HOST:135.

Expected Detection

SPL risk score elevates due to NewCredentialUse (4648) + PrivilegedLogons if svc_account has admin rights. Lateral movement hunting query flags WmiPrvSE parent-child process chain on target host.

Test 3 Simulate Dormant Account Reactivation (Local)

windows

Creates a disabled local account, enables it, and performs a local interactive logon to simulate adversary reactivation of a dormant/inactive account — a technique used by groups like Scattered Spider to abuse former employee accounts. Requires local admin.

Command

powershell

net user df00tech_dormant TempPass123! /add /comment:"Test dormant account"
net user df00tech_dormant /active:no
ping -n 3 127.0.0.1 > nul
net user df00tech_dormant /active:yes
runas /user:df00tech_dormant cmd.exe

Cleanup

powershell

net user df00tech_dormant /delete

Expected Telemetry

Security Event ID 4720 (account created). Security Event ID 4725 (account disabled). Security Event ID 4722 (account enabled — key indicator of reactivation). Security Event ID 4624 LogonType=2 (interactive) for df00tech_dormant. Audit event for account enabling action.

Expected Detection

Dormant account hunting query matches df00tech_dormant (disabled then re-enabled). Event ID 4722 followed quickly by 4624 for an account with no prior logon history triggers escalation criteria.

Test 4 Simulate Cloud Account Compromise via Azure CLI

linux

Authenticates to Azure using compromised credentials and enumerates resources, simulating Initial Access via cloud console access as performed by groups like Scattered Spider and Volt Typhoon. Uses the Azure CLI — install with: curl -sL https://aka.ms/InstallAzureCLIDeb | sudo bash

Command

bash

az login --username [email protected] --password 'CompromisedPassword1!'
az account list --output table
az ad signed-in-user show
az role assignment list --assignee [email protected]

Cleanup

bash

az logout

Expected Telemetry

Azure AD SigninLogs entry with UserPrincipalName=compromised_user, AppDisplayName='Microsoft Azure CLI', ClientAppUsed='Other clients', AuthenticationRequirement='singleFactorAuthentication' (if no MFA). Azure Audit Log entries for resource enumeration. Entra ID Protection may generate a risk detection if login is from an unexpected location.

Expected Detection

KQL anomaly detection fires if location or IP is new relative to 14-day baseline. AnomalyScore includes NewLocation + NewApp (CLI vs. browser) = 2, meeting threshold. Missing MFA event adds to escalation criteria.

Test 5 Test Impossible Travel Detection Trigger

linux

Performs sequential authentications using VPN endpoints in geographically separated regions within a short time window to test impossible travel detection logic. Requires access to two VPN exit nodes in different countries/regions. This validates that your SIEM correctly identifies the impossible travel pattern.

Command

bash

# Connect to VPN exit node 1 (e.g., US)
echo '[+] Authenticating from VPN endpoint 1 (US)'
curl -s -X POST 'https://login.microsoftonline.com/TENANT_ID/oauth2/v2.0/token' \
  -d 'grant_type=password&client_id=CLIENT_ID&[email protected]&password=TestPass1!&scope=openid'
sleep 120
# Connect to VPN exit node 2 (e.g., EU) and repeat authentication
echo '[+] Authenticating from VPN endpoint 2 (EU) - switch VPN now'
curl -s -X POST 'https://login.microsoftonline.com/TENANT_ID/oauth2/v2.0/token' \
  -d 'grant_type=password&client_id=CLIENT_ID&[email protected]&password=TestPass1!&scope=openid'

Cleanup

bash

# Revoke test sessions in Entra ID admin portal or via: az ad user revoke-sign-in-sessions --id [email protected]

Expected Telemetry

Two SigninLogs entries for [email protected]: first from US IP, second from EU IP approximately 2 minutes later. Entra ID Protection should generate an 'Impossible Travel' risk detection. Both entries appear in the 24h window, different Location fields.

Expected Detection

KQL hunting query for 3+ countries in 24h may not fire for only 2 countries — adjust to 2+ for testing. Entra ID Protection impossible travel detection fires independently. AnomalyScore on second login = 2 (NewLocation + NewIP), meeting KQL alert threshold.

Related Detections

Tactic Hubs

TA0001Initial Access TA0003Persistence TA0004Privilege Escalation TA0005Defense Evasion

What is T1078 Valid 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 T1078

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

Command

Cleanup

Expected Telemetry

Expected Detection

Command

Cleanup

Expected Telemetry

Expected Detection

Related Detections

Tactic Hubs

Sub-techniques (4)

Related Techniques

Same Tactic: Initial Access

Popular Detections

Get new detections in your inbox