AN1524: Analytic 1524
Multiple failed sign-in attempts from external sources across many users followed by success from the same IP
Analyst context for executives and security teams
This analytic points to a practical identity-risk pattern: an external source fails to sign in across many users, then succeeds from the same IP. For leaders, the value is not the analytic name; it is whether the organization can quickly tell the difference between normal authentication noise and a possible credential attack that has produced a valid login in the identity provider.
Executive priority
Prioritize this as an identity monitoring and incident-response readiness question. If identity provider logs are incomplete, delayed, or not correlated across users and source IPs, SOC teams may miss the moment when broad failed sign-in activity turns into a successful authentication. Executives should ask whether external authentication telemetry is retained, monitored, and usable as evidence for incident decisions, access reviews, and compliance reporting.
Technical view
Validate whether the SOC can detect multiple failed sign-in attempts from external sources across many users followed by a successful sign-in from the same IP in the identity provider. Because no official detection logic or ATT&CK tactic is supplied, teams should define local thresholds for 'many users,' time window, external source classification, and success-after-failure sequencing. Triage should focus on whether the successful account, source IP, and timing are expected for the environment.
Likely telemetry
- Identity provider sign-in logs
- Authentication failure and success events
- Source IP address and external/internal source context
- User/account identifiers across failed and successful attempts
- Timestamps sufficient to correlate sequence and time window
Detection direction
- Correlate failed sign-in attempts across multiple users by source IP, then alert when a successful sign-in from that same IP follows within a defined window.
- Tune thresholds to reduce noise from shared infrastructure, user mistakes, VPN/proxy egress, and legitimate third-party access patterns.
- Require enrichment for source IP reputation or ownership only if available locally; do not depend on enrichment as the sole detection condition.
- Validate that successful sign-ins are not filtered out of collection, since the success event is the key risk pivot in this analytic.
- Document gaps where identity provider logging, retention, or cross-user correlation is unavailable.
Mitigation priorities
- Ensure identity provider authentication logs are centrally collected with enough retention for investigation.
- Harden identity access controls that reduce risk from successful sign-ins after password guessing, such as MFA and conditional access, where appropriate to the environment.
- Review incident-response playbooks for rapid validation of suspicious successful sign-ins, including account review and session handling.
- Use the analytic as audit evidence that identity monitoring covers both failed attempts and subsequent successful access, not only lockouts or high failure counts.
Analyst notes and limits
The supplied ATT&CK object is a detection analytic for the Identity Provider platform with the description: multiple failed sign-in attempts from external sources across many users followed by success from the same IP. No relationships, tactics, or official detection implementation are supplied, so local engineering must define thresholds, time windows, and exception handling.
This take is limited to the official STIX fields and the single external reference provided. It does not assert adversary attribution, active exploitation, impact, or guaranteed detection coverage. Environment-specific identity provider logging and business access patterns are required to operationalize the analytic.
Analytic 1524
Multiple failed sign-in attempts from external sources across many users followed by success from the same IP
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 | ed2f11f5158d… |
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 AN1524Open 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.