AN0295: Analytic 0295
Sudden valid logins from accounts that previously had credentials dumped but had not authenticated successfully in the past; correlated with timeline of suspected hash cracking
Analyst context for executives and security teams
This analytic is about a high-risk identity pattern: accounts tied to previously dumped credentials suddenly start logging in successfully after a period with no successful authentication, especially when the timing aligns with suspected hash cracking. For leaders, the value is in validating whether identity monitoring can connect credential exposure history with later login activity, rather than treating each login as an isolated event.
Executive priority
Prioritize this as an identity and incident-response readiness question: can the organization prove which exposed accounts were reset, disabled, monitored, or allowed to authenticate again? This matters for business continuity because valid logins using compromised credentials may bypass many perimeter controls and can complicate incident scoping, audit evidence, and account recovery decisions.
Technical view
SOC and identity teams should validate whether the identity provider can correlate three things over time: accounts known or suspected to have had credentials dumped, historical absence of successful authentication, and new successful logins. Because no ATT&CK detection logic is supplied, teams should treat this as a detection-design requirement rather than a ready-made rule. The key engineering challenge is maintaining reliable account exposure context and comparing it against authentication timelines.
Likely telemetry
- Identity provider successful authentication logs
- Historical account login activity or inactivity records
- Records of accounts associated with dumped or exposed credentials
- Incident timeline data for suspected hash cracking activity
- Account status, password reset, and credential rotation records
Detection direction
- Validate that exposed-account lists are preserved and queryable, not only stored in incident notes.
- Alert on successful logins from accounts previously associated with dumped credentials, especially after long inactivity or no prior successful authentication.
- Correlate authentication timing with suspected hash cracking timelines when such timeline evidence exists.
- Tune for legitimate account reactivation, service account behavior, password resets, and help desk recovery workflows to reduce false positives.
- Review blind spots where identity provider logs are short-retained, normalized poorly, or not linked to incident-response evidence.
Mitigation priorities
- Ensure accounts associated with dumped credentials are reset, disabled, or otherwise remediated before they can authenticate again.
- Require strong identity recovery and credential rotation procedures for exposed accounts.
- Maintain auditable records connecting credential exposure findings to remediation actions.
- Improve identity provider log retention and correlation so SOC and IR teams can reconstruct account activity over time.
- Use this analytic as a control-validation exercise for identity monitoring and incident response handoff processes.
Analyst notes and limits
The supplied ATT&CK object is a detection analytic for the Identity Provider platform. It provides a concise behavioral description but no official detection logic, tactics, relationships, aliases, or mitigation text. The most defensible use is to guide validation of identity telemetry correlation around dumped credentials and later successful logins.
No relationship context, ATT&CK tactics, or official detection procedure was supplied. Local determinations are required for what counts as credential dumping evidence, suspected hash cracking timeline evidence, account inactivity, and legitimate reactivation.
Analytic 0295
Sudden valid logins from accounts that previously had credentials dumped but had not authenticated successfully in the past; correlated with timeline of suspected hash cracking
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 | 124d39a83817… |
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 AN0295Open 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.