A stolen password works just as well from another continent, so where a sign-in comes from is often the first visible difference between the real user and an attacker. MITRE D3FEND names this countermeasure User Geolocation Logon Pattern Analysis (D3-UGLPA) and defines it as "Monitoring geolocation data of user logon attempts and comparing it to a baseline user behavior profile to identify anomalies in logon location." It sits under the Detect tactic as a child of User Behavior Analysis. This card covers how the analytic works, how to read D3FEND's very broad ATT&CK mapping for it, where identity platforms implement it, how to test that travel and new-location alerts actually fire, and the bypasses that make location a weak signal on its own. It is for identity security teams, detection engineers and SOC leads.
Key takeaways
- Three patterns, per D3FEND. Logons from a location the user does not usually use, from a location where the organisation has no users, and logons that are physically impossible given the time since the previous one.
- It finds stolen credentials, not attacks on the network. D3FEND's inferred ATT&CK list is long because the analytic is tied to the Network Traffic artefact; the practical value is against valid account abuse, password spraying, credential stuffing and token replay.
- IP geolocation is approximate. VPNs, cloud proxies, mobile carriers and residential proxies all distort location, so tune for your egress points before you trust the alerts.
- Use it to step up, not only to alert. The strongest use feeds the risk into sign-in policy (require phishing-resistant MFA, block, or reset) rather than leaving a queue of travel alerts.
- Workloads need their own baseline. Service accounts, keys and tokens normally come from fixed networks, so an unexpected source network for a non-human identity is often a stronger signal than for a person.
D3-UGLPA at a glance
| Attribute | Value |
|---|---|
| D3FEND ID | D3-UGLPA (d3f:UserGeolocationLogonPatternAnalysis) |
| Tactic | Detect |
| Parent technique | User Behavior Analysis |
| Digital artefact | Network Traffic (D3FEND relation: analyzes Network Traffic) |
| Siblings | Authentication Event Thresholding, Authorization Event Thresholding, Job Function Access Pattern Analysis, Resource Access Pattern Analysis, Session Duration Analysis, User Data Transfer Analysis, Web Session Activity Analysis and others |
| D3FEND references | Patents from Exabeam (behaviour model histograms including geo-location of logon origination) and Idaptive (entity profile including logon locations, with step-up MFA on risk) |
| Related ATT&CK mitigation in D3FEND | M1040 Behavior Prevention on Endpoint |
| Data needed | Sign-in logs with source IP, timestamp, result, user, client and device; an IP geolocation source; a list of corporate egress and VPN addresses |
| Main limitation | Location is inferred from IP and is easy to fake with a proxy near the victim |
How it works
D3FEND describes the analytic in two steps: geolocation data for each logon attempt builds a baseline profile, and current logons are compared against it. Deviations "can help in identifying situations that may be indicative of a remote attacker using stolen credentials". D3FEND's considerations warn of false positives from benign anomalies and note that attackers may not differ enough to trigger an alert. In practice, implementations use three tests.
| Test | D3FEND example | Typical implementation | Common false positive |
|---|---|---|---|
| New location for this user | "logons from locations that are different from where a user usually logs in" | Compare city, region, country or a radius against the user's recent successful sign-ins | Business travel, holidays, new home address |
| Location with no users | "logons from a location in which an enterprise has no users located" | Organisation-wide list of expected countries, enforced as a named location or a rule | Remote contractors, suppliers, staff on leave abroad |
| Impossible travel | "logon that is not physically possible given the elapsed time since a logon from another location" | Distance between two consecutive sign-ins divided by elapsed time, compared with a speed threshold | VPN connect and disconnect, mobile data, cloud proxies, split tunnelling |
The Exabeam reference describes the model as histograms per user (client devices, servers, logon time of day and day of week, geo-location of logon origination) with an initial training period, for example 90 days, before scoring starts. The Idaptive reference adds the response side: a credible risk at logon can require more authentication factors, and risky behaviour after logon can end the session or reduce privileges.
Where identity fits
This is an identity control first. It works on sign-in events, and its best outcome is an identity decision: step-up, session revocation or credential reset. For non-human identities the baseline is simpler and stricter. A deployment pipeline's key or a workload's token should only ever appear from known networks, so any other source is worth an alert. AWS GuardDuty, for example, raises UnauthorizedAccess:IAMUser/InstanceCredentialExfiltration.OutsideAWS when EC2 instance credentials are used from an external IP address. See the Impossible Travel and Anomalous Sign-In Detection guide for wider sign-in analytics and the MITRE ATT&CK T1078 Valid Accounts Guide for the attacker side.
ATT&CK techniques D3FEND relates to D3-UGLPA
Relationship type: inferred only. D3FEND lists every relation as inferred and experimental, derived because D3-UGLPA analyzes Network Traffic and many ATT&CK techniques produce network traffic (D3FEND 1.6.0, checked November 2026). The list on the D3FEND site runs across Persistence, Privilege Escalation, Lateral Movement, Credential Access, Discovery, Exfiltration, Initial Access, Command and Control, Stealth, Collection, Execution and Impact. The table groups the IDs D3FEND shows by tactic and adds NHI Mgmt Group's view of where a location analytic genuinely helps; each ID was checked against ATT&CK v20.
| Tactic (as D3FEND groups it) | ATT&CK IDs D3FEND lists | Practical value of logon geolocation (NHI Mgmt Group view) |
|---|---|---|
| Credential Access | T1110.003 Password Spraying, T1110.004 Credential Stuffing, T1557.001, T1557.003, T1003.006, T1558.003 | High for spraying and stuffing: attempts arrive from unusual countries and hosting networks. Low for the on-network techniques |
| Lateral Movement | T1021.001 RDP, T1021.004 SSH, T1550.001 Application Access Token, T1550.004 Web Session Cookie | High for token and cookie replay from a new location; medium for remote services exposed to the internet |
| Persistence and Privilege Escalation | T1098.001 Additional Cloud Credentials, T1546.003, T1546.008, T1542.005, T1205.001 | Medium for T1098.001 when the change is made from an unusual location; low for host-level techniques |
| Initial Access and Execution | T1566.001, T1566.002, T1204.001 | Indirect: catches the later sign-in with phished credentials, not the phish |
| Exfiltration | T1567.001, T1567.002, T1048.001, T1048.002, T1048.003 | Low: data volume analytics fit better (see User Data Transfer Analysis) |
| Command and Control | T1071.001 to T1071.004, T1090.001 to T1090.004, T1573.001, T1573.002, T1205.001 | Low; network analytics fit better |
| Stealth, Collection, Impact | T1218.003, T1542.005, T1557.001, T1557.003, T1565.002, T1498.001, T1498.002, T1499.002 | Low |
D3FEND also lists parent techniques without IDs on the page, including Remote System Discovery, Phishing, Brute Force and Use Alternate Authentication Material. Treat the table as a map of where network traffic exists, not as a coverage claim. The deeper attacker pages are the MITRE ATT&CK T1110 Brute Force Guide and the MITRE ATT&CK T1550 Use Alternate Authentication Material Guide.
Where it is implemented
Most organisations get D3-UGLPA from their identity provider or cloud platform rather than building it. Examples follow, listed alphabetically by vendor; naming them explains the mechanism and is not a recommendation.
| Platform | Location-related detections or settings (from vendor documentation) | How the result is used |
|---|---|---|
| Amazon Web Services (GuardDuty) | UnauthorizedAccess:IAMUser/ConsoleLoginSuccess.B (successful console logins for one IAM user from different locations around the same time); instance and resource credential exfiltration findings; */IAMUser/AnomalousBehavior findings where originating location is one factor | Findings for triage and automated response |
| Google Workspace (alert center) | "Suspicious login blocked", "Suspicious programmatic login" and "Suspicious login from a less secure app", with an unusual location among the triggers; alert details include the IP address | Alerts; Google blocks suspicious programmatic logins |
| Microsoft Entra ID Protection | Atypical travel (unlikelyTravel, real time), Impossible travel and New country (detected via Defender for Cloud Apps, offline), Unfamiliar sign-in properties (IP, ASN, location, device, browser; learning mode of at least five days for new users) | Sign-in risk feeding Conditional Access; named locations by IP range or country |
| Okta (Behavior Detection) | New City (last 20 sign-ins by default), New State (15), New Country (10), New Geo-Location (20 sign-ins, 20 km radius), New IP (50), Velocity (default 805 km/h) | Conditions in sign-on policies, for example require MFA on a new country |
Availability: service, plan and licence requirements apply to these features and differ by vendor and edition. Confirm against each vendor's current documentation. A SIEM or UEBA platform can run the same tests across several identity providers; see the UEBA Guide and the ITDR Guide.
Implementation steps
- Collect the right sign-in data. Every identity provider and every internet-facing service that authenticates users: IdP sign-in logs, VPN, cloud consoles, SaaS admin portals. Keep source IP, timestamp, result, client and device.
- Build the egress list. Record corporate egress IPs, VPN concentrators, secure web gateway and cloud proxy ranges. Mark them as trusted named locations or exclusion lists, otherwise every proxy change looks like travel.
- Set organisation-wide expectations. Agree the countries where you have staff and suppliers. Sign-ins from elsewhere become a policy decision (block or step up), not just an alert.
- Turn on per-user analytics in report mode. Enable the platform's travel and new-location detections and run them for at least two to four weeks (an example period, not a standard), so baselines settle and you see the false positive rate.
- Connect risk to action. Medium risk: require phishing-resistant MFA. High risk or impossible travel followed by a successful sign-in: revoke sessions and reset the credential. Okta's documentation notes that its behaviour detection cannot deny access by itself, so the policy design matters.
- Baseline non-human identities separately. For service accounts, API keys and workload tokens, list the expected source networks and alert on anything else. Do not let a person's travel exceptions apply to them.
- Roll back safely. Location blocks can lock out real users. Keep a break-glass account excluded from location policies, test with a pilot group, and return policies to report-only mode if lockouts rise.
For policy design, see the Conditional Access Guide and How to Find Accounts Excluded From MFA and Conditional Access.
How to verify it works
- Controlled travel test: with a test account, sign in from the office, then within an hour from a cloud VM in another country (an approved, documented test). Confirm the travel or new-country detection fires, the policy response applies and the alert reaches the SIEM.
- Unexpected-country test: sign in from a country outside the organisation's list and confirm the block or step-up.
- Egress change test: when the network team changes a VPN or proxy range, check whether detections spike; if they do, the egress list is out of date.
- Workload test: use a test key or token from an unapproved network and confirm the non-human identity alert fires.
- Look-back test: pick a confirmed account compromise from your incident history and check whether the analytic would have flagged the attacker's first sign-in.
| Metric | Example target (NHI Mgmt Group suggestion, not a standard) | Why it matters |
|---|---|---|
| Controlled travel tests that alert and trigger the policy | 100% | End-to-end proof |
| Travel alerts closed as benign VPN or proxy noise | Falling month on month | Shows the egress list is maintained |
| Location risk events resolved by automatic step-up rather than analyst triage | Rising | Moves the control from alert to prevention |
| Non-human identities with a defined expected source network | Rising towards all privileged ones | Workload baselines are the cleanest signal |
| Confirmed compromises where location was the first signal | Tracked per quarter | Shows real detection value |
Limits, bypasses and failure patterns
- Residential and local proxies: attackers who route through a proxy in the victim's city or on a consumer ISP look local. Location alone does not catch them; device and session signals are needed.
- Adversary-in-the-middle phishing: the victim signs in from their usual location through the attacker's proxy, and the stolen session cookie is then replayed. The replay may be the only location anomaly. See the AiTM Phishing Guide.
- Trusted location sprawl: large trusted ranges (whole cloud provider ranges, guest Wi-Fi) give attackers a free pass if they land there.
- Proxy and VPN noise: Microsoft's documentation notes Entra ID evaluates the proxy's IP address and does not use X-Forwarded-For; unmaintained egress lists drown the SOC in false travel alerts until people stop reading them.
- Alerts with no action: travel alerts that only go to a queue are seen hours later. Tie them to step-up or session revocation.
- Service accounts excluded from location policy: exclusions added for automation are rarely revisited and become the preferred path for stolen keys.
Framework mapping
| Framework | Reference | Relevance |
|---|---|---|
| MITRE D3FEND | User Behavior Analysis, D3-UGLPA | Parent and technique |
| MITRE ATT&CK mitigations | M1040 Behavior Prevention on Endpoint (D3FEND related); M1032 Multi-factor Authentication, M1036 Account Use Policies (NHI Mgmt Group view) | Related mitigation in D3FEND; controls that act on the risk signal |
| NIST SP 800-53 Rev 5 | AC-2 Account Management, AC-7 Unsuccessful Logon Attempts, SI-4 System Monitoring, AU-6 Audit Record Review, Analysis, and Reporting | Atypical account use, failed logon patterns, monitoring and review |
| NIST CSF 2.0 | DE.CM-03, DE.AE-02 | Monitoring personnel activity; analysing adverse events |
Control detail is in M1032 Multi-factor Authentication and M1036 Account Use Policies.
Related countermeasures
- Session Duration Analysis (D3-SDA): sibling analytic on how long sessions last. See D3-SDA Session Duration Analysis.
- User Data Transfer Analysis (D3-UDTA): sibling analytic on data volumes after logon. See D3-UDTA User Data Transfer Analysis.
- IP Reputation Analysis (D3-IPRA): adds what is known about the source IP (anonymiser, hosting, known bad). See D3-IPRA IP Reputation Analysis.
- Multi-factor Authentication (D3-MFA): the usual response to a location risk. See D3-MFA Multi-factor Authentication.
Practitioner checklist
- Collect sign-in logs with source IP from every identity provider and internet-facing login.
- Maintain a list of corporate egress, VPN and proxy ranges and review it at every network change.
- Define the countries where the organisation operates and block or step up elsewhere.
- Run travel and new-location detections in report mode before enforcing.
- Connect location risk to step-up MFA, session revocation or credential reset.
- Define expected source networks for privileged non-human identities and alert on others.
- Keep break-glass accounts excluded and monitored separately.
- Run a controlled travel test each quarter and after policy changes.
Standards and references
- MITRE D3FEND: User Geolocation Logon Pattern Analysis (D3-UGLPA)
- Google Patents: US20190034641A1 Detecting and assessing security risks in a network (Exabeam)
- Google Patents: US20190081968A1 Network fraud detection and remediation through analytics (Idaptive)
- NIST: SP 800-53 Rev. 5 Security and Privacy Controls
- AWS: GuardDuty IAM finding types
- Google Workspace Admin Help: View alert details
- Microsoft Learn: Risk detections in Microsoft Entra ID Protection
- Microsoft Learn: Network assignment in Conditional Access (named locations)
- Okta: About behavior detection
Related NHI Mgmt Group resources: Impossible Travel and Anomalous Sign-In Detection · MITRE D3FEND Guide · UEBA Guide · Identity Threat Hunting Guide · Entra ID Sign-In and Audit Log Detection Guide