DET0460: Credential Stuffing Detection via Reused Breached Credentials Across Services
DET0460 is a detection strategy for spotting credential stuffing by looking for reuse of breached credentials across services. Its business significance is...
Analyst context for executives and security teams
DET0460 is a detection strategy for spotting credential stuffing by looking for reuse of breached credentials across services. Its business significance is identity risk: a password exposed outside the organization can become a path into business systems when users reuse credentials. Because the ATT&CK object has no official detection text or platform list of its own, teams should treat this as a validation prompt for identity-provider and service-login monitoring tied to the related Credential Stuffing technique T1110.004.
Executive priority
Prioritize this where compromised accounts could disrupt operations, expose regulated data, or create audit gaps around account protection. Leaders should ask whether the organization can prove it detects suspicious login attempts using known-breached or reused credentials across identity provider, IaaS, container, and ESXi-related access paths identified in the related ATT&CK technique. This is also a control-evidence issue: MFA, password hygiene, breached-password screening, and centralized authentication logging are only useful if coverage and alert handling are demonstrable.
Technical view
For SOC, detection engineering, and IR teams, validate whether login telemetry can correlate repeated authentication attempts, credential reuse patterns, known-breached credential indicators, and account takeover signals across relevant services. The relationship context maps this strategy to T1110.004 Credential Stuffing under credential access, with related platforms of Containers, ESXi, IaaS, and Identity Provider. Because DET0460 does not provide official detection logic, detection content should be locally engineered and tested against available authentication, identity, and service access logs without assuming platform coverage beyond the related technique.
Likely telemetry
- Identity provider authentication logs
- Application and service login logs
- Cloud/IaaS authentication and access logs where available
- Container platform access/authentication logs where applicable
- ESXi or virtualization management authentication logs where applicable
Detection direction
- Confirm which services actually emit authentication events into the SOC pipeline; credential stuffing is often missed when only the primary identity provider is monitored.
- Correlate failed and successful authentication activity across accounts, services, source infrastructure, and time windows rather than relying on single-event alerts.
- Tune for false positives from legitimate password resets, user travel, shared networks, mobile carrier NAT, SSO migrations, and automated business integrations.
- Look for successful logins following repeated failures or use of credentials flagged as breached, where that data source exists.
- Validate coverage for the related ATT&CK platforms: Identity Provider, IaaS, Containers, and ESXi, but do not assume all are in scope for every environment.
Mitigation priorities
- Reduce credential reuse risk with MFA and phishing-resistant authentication where feasible, especially for high-value and externally accessible services.
- Implement breached-password and weak-password controls where supported by the identity stack.
- Centralize authentication logging from identity providers and critical services before relying on detection logic.
- Apply rate limiting, lockout, adaptive access, and risk-based authentication carefully to balance security with business availability.
- Review privileged, service, cloud, and administrative accounts for stronger authentication and monitoring requirements.
Analyst notes and limits
The supplied ATT&CK detection strategy has no official description, detection text, tactics, or platforms. The useful context comes from its relationship to T1110.004 Credential Stuffing, which describes adversaries using credentials from unrelated breach dumps because users may reuse passwords across personal and business accounts. Treat this Glexia take as defensive planning guidance, not as a complete analytic specification.
Coverage, data availability, and alert fidelity depend on the local identity architecture, logging configuration, breached-credential data sources, and service integrations. The supplied fields do not support claims of active exploitation, attribution, guaranteed detection, or specific vendor controls.
Credential Stuffing Detection via Reused Breached Credentials Across Services
No official description is available in the imported ATT&CK source object.
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.
Techniques used
This mirrors the MITRE pattern of making group, software, campaign, and technique relationships scannable. Relationship notes come from mirrored ATT&CK relationship text when available.
| Domain | ID | Name | Relationship / procedure |
|---|---|---|---|
| Enterprise | T1110.004 | Credential Stuffing Sub-technique | This object detects Credential Stuffing. |
All related ATT&CK context
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 | 536a19319320… |
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 DET0460Open 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.