AN1275: Analytic 1275
High volume of failed logon attempts followed by a successful one from a suspicious user, host, or timeframe
Analyst context for executives and security teams
This analytic matters because a burst of failed Windows logon attempts followed by a successful logon can be an early warning that an account, host, or login window deserves immediate review. For leaders, the value is not just finding bad passwords; it is confirming whether the organization can quickly distinguish normal user error from credential misuse before access becomes a broader incident.
Executive priority
Prioritize this as an identity and SOC readiness check: can teams prove they collect Windows logon evidence, correlate failures to later success, and escalate suspicious patterns fast enough to protect business operations? It also supports audit and incident-response evidence by showing whether authentication monitoring can reconstruct who logged in, from where, and after what failure pattern.
Technical view
Validate detection logic on Windows authentication events that identifies a high volume of failed logon attempts followed by a successful logon, scoped by user, host, and timeframe. Because ATT&CK provides no detailed detection implementation or tactic mapping for this analytic, SOC teams should define local thresholds, time windows, and suspicious-user/host criteria based on normal authentication behavior. Tuning should account for benign causes such as password changes, expired credentials, mistyped passwords, service-account misconfiguration, scheduled tasks, and lockout recovery.
Likely telemetry
- Windows security logon events showing failed authentication attempts
- Windows security logon events showing successful authentication
- User/account identifiers associated with each attempt
- Source and destination host information where available
- Timestamps sufficient to correlate failures followed by success
Detection direction
- Confirm Windows logon telemetry is collected centrally and retained long enough for correlation.
- Build or validate correlation that links repeated failed logons to a subsequent successful logon for the same user, host, or relevant source context.
- Tune thresholds and timeframes against local baselines to reduce noise from normal user error and recurring misconfigured services.
- Review suspicious timeframe logic, such as unusual hours for the user or host, only where local business patterns support it.
- Ensure triage playbooks capture whether the successful logon led to additional suspicious activity, without assuming compromise from this analytic alone.
Mitigation priorities
- Strengthen identity controls that reduce repeated guessing risk, such as account lockout policy and multi-factor authentication where appropriate.
- Maintain accurate ownership and expected behavior for privileged, service, and shared accounts to support triage.
- Investigate and remediate misconfigured applications or services that generate repeated failed logons.
- Ensure incident response procedures define escalation criteria for suspicious failure-to-success authentication patterns.
- Use findings from recurring alerts to improve password policy, access reviews, and authentication monitoring coverage.
Analyst notes and limits
This is a detection analytic object for Windows with the official description: high volume of failed logon attempts followed by a successful one from a suspicious user, host, or timeframe. No ATT&CK tactic, technique relationship, or official detection logic was supplied, so the take focuses on defensible monitoring and validation rather than asserting a specific adversary behavior.
The source object is sparse: no relationships, no tactic mapping, and no official detection implementation are provided. Local event IDs, thresholds, baselines, and escalation rules must be determined from the organization’s Windows logging configuration and authentication patterns.
Analytic 1275
High volume of failed logon attempts followed by a successful one from a suspicious user, host, or timeframe
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 | a8c5c6536acb… |
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 AN1275Open 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.