Potential Account Takeover - Logon from New Source IP

IMPORTANT: This documentation is no longer updated. Refer to Elastic's version policy and the latest documentation.

Potential Account Takeover - Logon from New Source IP

Identifies a user account that normally logs in with high volume from one source IP suddenly logging in from a different source IP. This pattern (one IP with many successful logons, another IP with very few) may indicate account takeover or use of stolen credentials from a new location.

Rule type: esql

Rule indices: None

Severity: medium

Risk score: 47

Runs every: 14m

Searches indices from: now-15m (Date Math format, see also Additional look-back time)

Maximum alerts per execution: 100

References:

https://attack.mitre.org/techniques/T1078/

Tags:

Domain: Endpoint
OS: Windows
Use Case: Threat Detection
Tactic: Privilege Escalation
Data Source: Windows Security Event Logs
Resources: Investigation Guide

Version: 3

Rule authors:

Elastic

Rule license: Elastic License v2

Investigation guide

edit

Triage and analysis

Investigating Potential Account Takeover - Logon from New Source IP

An account that historically logs in many times from a single source IP (e.g. usual workstation or VPN) and then shows successful logons from exactly one other IP with a low count may indicate credential compromise and use from a new location (account takeover).

Possible investigation steps

Confirm with the account owner whether they recently logged in from the new source IP or from a new device/location.
Check the new source IP for reputation, geography, and whether it is expected (e.g. corporate VPN range vs unknown).
Correlate with other alerts for the same user or source IP (e.g. logon failures, password changes, MFA changes).
Review timeline: if the "new" IP logon is very recent compared to the high-count IP, treat as higher priority.

False positive analysis

Legitimate use from a second device (e.g. new laptop, second office, VPN from travel) can produce exactly two IPs with one IP having few logons. Tune threshold (e.g. max_logon >= 100) or add exclusions for known VPN/remote ranges if needed.
Service or shared accounts that are used from multiple jump hosts or scripts may show two IPs; consider excluding known service accounts.

Response and remediation

If takeover is confirmed: force password reset, revoke sessions, and enable or enforce MFA. Disable or lock the account until the user verifies identity.
Investigate how credentials may have been compromised (phishing, breach, endpoint) and address the vector.

Setup

edit

Setup

Audit Logon must be enabled to generate the events used by this rule. Setup instructions: https://ela.st/audit-logon

Rule query

edit

from logs-system.security*, logs-windows.forwarded*, winlogbeat-* metadata _id, _version, _index
| where event.category == "authentication" and event.action == "logged-in" and winlog.event_id == "4624" and
        event.outcome == "success" and winlog.logon.type in ("Network", "RemoteInteractive") and
		source.ip is not null and source.ip != "127.0.0.1" and not to_string(source.ip) like "*::*" and not user.name like "*$"
| stats logon_count = COUNT(*), host_names = VALUES(host.name) by user.name, user.id, source.ip
| stats
    Esql.max_logon = MAX(logon_count),
    Esql.min_logon = MIN(logon_count),
    Esql.unique_host_count = COUNT_DISTINCT(host_names),
    Esql.host_name_values = VALUES(host_names),
    Esql.source_ip_values = VALUES(source.ip),
    Esql.count_distinct_source_ip = COUNT_DISTINCT(source.ip) by user.name, user.id

// high count of logons is often associated with service account tied to a specific source.ip, if observed in use from a new source.ip it's suspicious
| where Esql.max_logon >= 1000 and (Esql.min_logon >= 1 and Esql.min_logon <= 5) and Esql.count_distinct_source_ip == 2 and Esql.unique_host_count >= 2
| eval source.ip = MV_FIRST(Esql.source_ip_values), host.name = MV_FIRST(Esql.host_name_values)
| KEEP user.name, user.id, host.name, source.ip, Esql.*

Framework: MITRE ATT&CK^TM

Tactic:
- Name: Privilege Escalation
- ID: TA0004
- Reference URL: https://attack.mitre.org/tactics/TA0004/
Technique:
- Name: Valid Accounts
- ID: T1078
- Reference URL: https://attack.mitre.org/techniques/T1078/

« Service Control Spawned via Script Interpreter SeDebugPrivilege Enabled by a Suspicious Process »