Live Active security incident? Get immediate response
MITRE ATT&CK® Analytic

AN1339: Analytic 1339

Sign-in failures across enterprise SSO applications or SaaS platforms from same IP address using the same password against multiple user identities

EnterpriseAN1339AnalyticObject v1.0 Modified
Glexia's Take

Analyst context for executives and security teams

Analyst confidence High

AN1339 is a detection analytic for a pattern that can indicate password-spraying or credential-stuffing pressure against enterprise SSO or SaaS logins: many failed sign-ins from the same IP address using the same password across multiple user identities. For leaders, the value is not the analytic name; it is whether identity-provider logging can reveal broad authentication abuse early enough to protect business applications and reduce account-lockout, fraud, and incident-response costs.

Executive priority

Prioritize this as an identity and SaaS resilience control. Executives should ask whether the organization can show evidence that SSO/SaaS authentication failures are centrally logged, correlated by source IP, password-use pattern, and affected identities, and reviewed quickly. This supports incident decision-making, compliance evidence for access monitoring, and budget prioritization around identity telemetry, alert triage, and response playbooks.

Technical view

SOC and detection teams should validate whether identity-provider telemetry can identify repeated failed sign-ins across enterprise SSO applications or SaaS platforms from the same IP address where the same password is attempted against multiple user accounts. Because the ATT&CK object provides no formal detection logic, thresholds, or tactic mapping, teams should tune locally: count distinct user identities, group by source IP, evaluate repeated failure patterns, and account for legitimate sources such as shared corporate egress, VPN gateways, proxies, or misconfigured integrations.

Likely telemetry

  • Identity provider sign-in failure logs
  • Enterprise SSO authentication events
  • SaaS platform authentication failure records
  • Source IP address and network location metadata
  • User identity/account identifiers involved in failed sign-ins

Detection direction

  • Confirm that SSO and SaaS sign-in failures are collected centrally and retained long enough for correlation.
  • Correlate failures by same source IP address across multiple user identities, with attention to repeated use of the same password if that field or derived signal is available in the identity platform.
  • Tune thresholds to separate broad account targeting from normal user mistakes, application misconfiguration, shared NAT/VPN egress, and automated business processes.
  • Validate whether telemetry exposes enough detail to distinguish same-password attempts; if not, document the blind spot and consider compensating analytics based on failure volume, identity diversity, and source consistency.
  • Use the analytic as an identity-monitoring validation case rather than assuming coverage, since the official detection field is not provided.

Mitigation priorities

  • Ensure enterprise SSO and SaaS authentication logs are enabled, centralized, normalized, and searchable by source IP, user identity, application, result, and time.
  • Maintain incident-response playbooks for suspicious authentication failure clusters, including account review, source investigation, and escalation criteria.
  • Review identity controls that reduce risk from repeated password-based failures, such as strong authentication policy, lockout/rate-limiting behavior, and monitoring of high-risk users, where supported by the environment.
  • Document monitoring coverage and response evidence for audit and compliance readiness around access-control monitoring.
  • Regularly test the analytic against benign simulations or historical data to tune false positives without claiming complete detection.
Analyst notes and limits

This object is a detection analytic, not a technique. The supplied ATT&CK fields identify the platform as Identity Provider and describe a specific sign-in failure pattern across SSO or SaaS applications. No tactics, relationships, aliases, or official detection logic were supplied, so the take focuses on defensive validation and telemetry requirements rather than adversary attribution or guaranteed coverage.

The official detection field is not provided, and no relationship context is supplied. Any threshold, severity, response action, or conclusion about exploitation must be determined from local identity-provider and SaaS telemetry. The analytic depends on whether the environment records enough detail to correlate source IP, affected identities, and same-password behavior.

Official MITRE ATT&CK definition

Analytic 1339

Sign-in failures across enterprise SSO applications or SaaS platforms from same IP address using the same password against multiple user identities

View the same entry on attack.mitre.org (MITRE-hosted reference; in-page links above use the Glexia ATT&CK library.)

Glexia analysis

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.

Relationship explorer

All related ATT&CK context

No relationships are available in the current normalized data for this object.

Change history

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 .

ATT&CK release
19.1
Object version
1.0
Created
Modified
Raw hash
67d21a04714cf1f9...
Imported snapshots across ATT&CK releases (1)
Release Bundle imported Object version Modified Status Raw hash
19.1 1.0 Current bundle 67d21a04714c…
Raw source

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.

Source references

External references and citations

MITRE external references are preserved separately from Glexia analysis so citations remain traceable to their original source records.

  1. [1]
    mitre-attack AN1339
    Open source URL
Source and licensing

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.