AN1503: Analytic 1503
Detects anomalous authentication activity such as sign-ins from impossible geolocations or legacy protocols from high-privileged accounts.
Analyst context for executives and security teams
This analytic matters because unusual identity-provider sign-ins can be an early warning that important accounts are being misused. For leaders, the value is not just “detect impossible travel”; it is proving that the organization can see risky authentication patterns involving privileged users before they turn into broader access, response, or audit problems.
Executive priority
Prioritize this as an identity security and SOC readiness control for privileged access. Executives should ask whether authentication logs from the identity provider are complete, retained, and reviewed with enough context to distinguish real travel, VPN use, legacy protocol use, and account risk. This analytic can support compliance and incident decision-making by showing that privileged authentication anomalies are monitored, but the ATT&CK object does not provide enough detail to claim coverage by itself.
Technical view
Validate detection logic against Identity Provider telemetry for anomalous authentication activity, specifically sign-ins from impossible geolocations and use of legacy protocols by high-privileged accounts. Because no ATT&CK detection implementation or related techniques are supplied, SOC teams should define local thresholds, privileged-account scope, geolocation handling, and exception logic based on their environment.
Likely telemetry
- Identity provider sign-in logs
- User account and privilege/role context
- Source IP address and derived geolocation
- Authentication protocol or client type
- Timestamped authentication events
Detection direction
- Confirm that identity-provider logs include source IP, time, user, privilege context, and protocol/client details.
- Tune impossible-geolocation logic to account for VPNs, proxies, mobile networks, business travel, and shared egress points.
- Give higher priority to anomalies involving high-privileged accounts, as specified by the analytic description.
- Validate whether legacy protocol usage is visible and consistently labeled in the identity-provider telemetry.
- Document false-positive handling and escalation criteria so alerts support incident response rather than becoming background noise.
Mitigation priorities
- Maintain an accurate inventory of high-privileged identity-provider accounts.
- Reduce or disable legacy authentication protocols where business requirements allow.
- Apply stronger access controls to privileged accounts, such as conditional access and strong authentication, where supported by the identity platform.
- Ensure identity logs are retained and available to SOC and incident response teams.
- Review privileged sign-in anomalies as part of identity security and compliance evidence processes.
Analyst notes and limits
This is a detection analytic object, not a technique. The supplied ATT&CK fields identify the platform as Identity Provider and describe anomalous authentication activity involving impossible geolocations or legacy protocols from high-privileged accounts. There are no supplied tactics, relationships, or official detection logic, so implementation should be based on local identity architecture and logging quality.
ATT&CK provides no official detection query, no relationship context, and no specific identity-provider product details for this object. Local validation is required before using this analytic as evidence of monitoring coverage or control effectiveness.
Analytic 1503
Detects anomalous authentication activity such as sign-ins from impossible geolocations or legacy protocols from high-privileged accounts.
How security teams should use this page
Treat this object as behavior context, not an attribution claim. Validate the related groups, software, data sources, and mitigations against official ATT&CK relationships and your own telemetry before making control-coverage decisions.
All related ATT&CK context
No relationships are available in the current normalized data for this object.
Object version and sync metadata
The fields below describe the current mirrored snapshot. When Glexia retains multiple ATT&CK source imports, you can open the table to compare the same object across releases (hashes and MITRE timestamps). For MITRE’s own release notes and roadmap, see ATT&CK resources — Updates .
Imported snapshots across ATT&CK releases (1)
| Release | Bundle imported | Object version | Modified | Status | Raw hash |
|---|---|---|---|---|---|
| 19.1 | 1.0 | Current bundle | f7b8ee67c8b7… |
Mirrored ATT&CK source object
The raw object is retained through the mirrored ATT&CK source bundle and object hash. The raw endpoint returns the exact object from the mirrored bundle when available.
External references and citations
MITRE external references are preserved separately from Glexia analysis so citations remain traceable to their original source records.
-
[1]
mitre-attack AN1503Open source URL
Source: MITRE ATT&CK®. © 2026 The MITRE Corporation. This work is reproduced and distributed with the permission of The MITRE Corporation. MITRE ATT&CK and ATT&CK are registered trademarks of The MITRE Corporation. Glexia is not affiliated with or endorsed by MITRE.