---
title: Potential Account Takeover - Logon from New Source IP
description: 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...
url: https://www.elastic.co/docs/reference/security/prebuilt-rules/rules/windows/privilege_escalation_takeover_new_source_ip
products:
  - Elastic Security
---

# 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**:
**Rule Severity**: medium
**Risk Score**: 47
**Runs every**: 14m
**Searches indices from**: `now-15m`
**Maximum alerts per execution**: 100
**References**:
- [[https://attack.mitre.org/techniques/T1078/](https://attack.mitre.org/techniques/T1078/)](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
- Noise: Medium
- Performance: Normal
- Rule Type: ES|QL
- Platform: Windows

**Version**: 4
**Rule authors**:
- Elastic

**Rule license**: Elastic License v2

## Setup

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

## Investigation guide


## 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.


## Rule Query

```esql
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
- Tactic:
  - Name: Privilege Escalation
  - Id: TA0004
  - Reference URL: [[https://attack.mitre.org/tactics/TA0004/](https://attack.mitre.org/tactics/TA0004/)](https://attack.mitre.org/tactics/TA0004/)
- Technique:
  - Name: Valid Accounts
  - Id: T1078
  - Reference URL: [[https://attack.mitre.org/techniques/T1078/](https://attack.mitre.org/techniques/T1078/)](https://attack.mitre.org/techniques/T1078/)