Potential Account Takeover - Mixed Logon Types

Identifies a user account (often a service account) that normally logs in with high volume using one logon type suddenly showing successful logons using a different logon type with low count. This pattern may indicate account takeover or use of stolen credentials from a new context (e.g. interactive or network logon where only batch/service was expected).

Elastic rule (View on GitHub)

 1[metadata]
 2creation_date = "2026/02/25"
 3integration = ["system", "windows"]
 4maturity = "production"
 5updated_date = "2026/05/04"
 6
 7[rule]
 8author = ["Elastic"]
 9description = """
10Identifies a user account (often a service account) that normally logs in with high volume using one logon type
11suddenly showing successful logons using a different logon type with low count. This pattern may indicate account
12takeover or use of stolen credentials from a new context (e.g. interactive or network logon where only batch/service
13was expected).
14"""
15from = "now-15m"
16interval = "14m"
17language = "esql"
18license = "Elastic License v2"
19name = "Potential Account Takeover - Mixed Logon Types"
20note = """## Triage and analysis
21
22### Investigating Potential Account Takeover - Mixed Logon Types
23
24A high-volume account (e.g. service account tied to a specific logon type such as Batch or Network) that also shows successful logons with a different logon type and low count may indicate credential compromise and use from a new context (account takeover or misuse).
25
26### Possible investigation steps
27
28- Confirm with the account owner or service owner whether the additional logon type is expected (e.g. new automation, RDP for maintenance).
29- Review which logon types appear in Esql.logon_type_values and which has the low count (likely the anomalous one).
30- Correlate with other alerts for the same user (e.g. logon from new source IP, password changes, MFA changes).
31- Check whether the account is a known service account; if so, verify if any new scripts or systems were authorized to use it.
32
33### False positive analysis
34
35- Legitimate expansion of use (e.g. service account also used for occasional interactive logon for troubleshooting) can trigger this. Tune thresholds (e.g. max_logon >= 1000, min_logon <= 10) or add exclusions for known service accounts with documented multi-context use.
36- New scheduled tasks or automation that use a different logon type may cause a short-lived spike in the "other" logon type; review over a longer window if needed.
37
38### Response and remediation
39
40- If takeover or misuse is confirmed: force password reset, revoke sessions, rotate service account credentials, and restrict logon type or source where possible.
41- Investigate how credentials may have been compromised and address the vector.
42"""
43
44setup = """## Setup
45
46Audit Logon must be enabled to generate the events used by this rule.
47Setup instructions: https://ela.st/audit-logon
48"""
49
50references = ["https://attack.mitre.org/techniques/T1078/"]
51risk_score = 47
52rule_id = "b2c3d4e5-f6a7-5b6c-9d0e-1f2a3b4c5d6e"
53severity = "medium"
54tags = [
55    "Domain: Endpoint",
56    "OS: Windows",
57    "Use Case: Threat Detection",
58    "Tactic: Privilege Escalation",
59    "Data Source: Windows Security Event Logs",
60    "Resources: Investigation Guide",
61]
62timestamp_override = "event.ingested"
63type = "esql"
64
65query = '''
66from logs-system.security*, logs-windows.forwarded*, winlogbeat-* metadata _id, _version, _index
67| WHERE event.category == "authentication" and event.action == "logged-in" and winlog.event_id == "4624" and
68        event.outcome == "success" and not user.id in ("S-1-5-18", "S-1-5-19", "S-1-5-20") and
69        to_lower(user.name) != "administrator"
70| STATS logon_count = COUNT(*), host_names = VALUES(host.name) by user.name, user.id, winlog.logon.type
71| STATS
72    Esql.max_logon = MAX(logon_count),
73    Esql.min_logon = MIN(logon_count),
74    Esql.unique_host_count = COUNT_DISTINCT(host_names),
75    Esql.host_name_values = VALUES(host_names),
76    Esql.logon_type_values = VALUES(winlog.logon.type),
77    Esql.count_distinct_logon_types = COUNT_DISTINCT(winlog.logon.type) by user.name, user.id
78
79// high count of logons is often associated with service account tied to a specific service, if observed in use with a different logon type it's suspicious
80| WHERE Esql.count_distinct_logon_types >= 2 and Esql.max_logon >= 1000 and (Esql.min_logon >= 1 and Esql.min_logon <= 10) and Esql.unique_host_count >= 2
81| EVAL winlog.logon.type = MV_FIRST(Esql.logon_type_values), host.name = MV_FIRST(Esql.host_name_values)
82| KEEP user.name, user.id, host.name, winlog.logon.type, Esql.*
83'''
84
85[[rule.threat]]
86framework = "MITRE ATT&CK"
87[[rule.threat.technique]]
88id = "T1078"
89name = "Valid Accounts"
90reference = "https://attack.mitre.org/techniques/T1078/"
91
92
93[rule.threat.tactic]
94id = "TA0004"
95name = "Privilege Escalation"
96reference = "https://attack.mitre.org/tactics/TA0004/"

Triage and analysis

Investigating Potential Account Takeover - Mixed Logon Types

A high-volume account (e.g. service account tied to a specific logon type such as Batch or Network) that also shows successful logons with a different logon type and low count may indicate credential compromise and use from a new context (account takeover or misuse).

Possible investigation steps

  • Confirm with the account owner or service owner whether the additional logon type is expected (e.g. new automation, RDP for maintenance).
  • Review which logon types appear in Esql.logon_type_values and which has the low count (likely the anomalous one).
  • Correlate with other alerts for the same user (e.g. logon from new source IP, password changes, MFA changes).
  • Check whether the account is a known service account; if so, verify if any new scripts or systems were authorized to use it.

False positive analysis

  • Legitimate expansion of use (e.g. service account also used for occasional interactive logon for troubleshooting) can trigger this. Tune thresholds (e.g. max_logon >= 1000, min_logon <= 10) or add exclusions for known service accounts with documented multi-context use.
  • New scheduled tasks or automation that use a different logon type may cause a short-lived spike in the "other" logon type; review over a longer window if needed.

Response and remediation

  • If takeover or misuse is confirmed: force password reset, revoke sessions, rotate service account credentials, and restrict logon type or source where possible.
  • Investigate how credentials may have been compromised and address the vector.

References

Related rules

to-top