DET0876: Detection of Compromise Accounts
DET0876 is a detection strategy for identifying compromised accounts used before an intrusion, specifically tied to ATT&CK technique T1586, Compromise Acco...
Analyst context for executives and security teams
DET0876 is a detection strategy for identifying compromised accounts used before an intrusion, specifically tied to ATT&CK technique T1586, Compromise Accounts. The business issue is that a trusted existing account or persona can make social engineering and targeting more credible, which can undermine user trust, executive communications, supplier interactions, and incident response assumptions before malware or direct access appears.
Executive priority
Treat this as a pre-intrusion risk signal rather than only a SOC alerting problem. Leaders should ask whether the organization can recognize when accounts or personas associated with the business, staff, partners, or targeting activity have been taken over, and whether there is an escalation path before those accounts are used to influence employees or customers. This supports resilience, fraud reduction, identity governance, and evidence for security control effectiveness, but the supplied ATT&CK object does not define specific platforms or a formal detection method.
Technical view
Because the official detection text is not provided, defenders should validate coverage around the related behavior: adversaries compromising existing accounts with services that can be used during targeting, including online personas that may be trusted by victims. SOC, IR, and threat intelligence teams should map which accounts matter for pre-incident targeting, what telemetry exists for abnormal authentication, ownership changes, profile changes, and unusual outreach, and how such signals are triaged when they occur outside traditional endpoint or network visibility.
Likely telemetry
- Authentication and login history for relevant accounts where available
- Account recovery events, password resets, MFA changes, and contact-detail changes
- Profile, display-name, biography, avatar, or account metadata changes
- Outbound messaging, connection requests, or contact activity from accounts used for outreach
- User, customer, partner, or third-party reports of suspicious communications from trusted personas
Detection direction
- Start by inventorying which accounts or personas could be abused for targeting and social engineering; without that scope, detection will be ad hoc.
- Correlate account-change events with unusual communication behavior rather than relying on a single signal, since legitimate travel, role changes, or marketing activity may create false positives.
- Define escalation criteria for suspected takeover of accounts that can influence employees, customers, suppliers, or executives, even when no internal compromise is yet confirmed.
- Validate whether telemetry exists for accounts outside core enterprise identity systems; external services and personas are a likely blind spot because the ATT&CK object is associated with PRE platform activity.
- Use relationship context to tune detections toward resource-development behavior, not only post-compromise activity inside the enterprise.
Mitigation priorities
- Prioritize ownership, recovery, and access-control hygiene for accounts and personas that could be used to target the organization or represent trusted relationships.
- Require documented response paths for suspected account compromise, including verification, containment, communication, and evidence preservation.
- Where supported by the service, enforce strong authentication and reduce shared or unmanaged account use.
- Educate high-risk users and support teams to report suspicious messages from otherwise trusted personas, because compromised existing accounts may appear more credible than newly created ones.
- Review third-party and external-service account governance as part of identity, incident response, and compliance readiness programs.
Analyst notes and limits
The supplied object is a detection strategy with no official description, no official detection logic, no platforms, and no tactics listed. The only behavioral anchor is its relationship to T1586, Compromise Accounts, under resource development with PRE platform context. This take therefore focuses on validation questions, telemetry classes, and governance implications rather than asserting specific analytic logic or coverage.
This summary cannot confirm specific data sources, platforms, analytic methods, detection effectiveness, active exploitation, or attribution because those details were not supplied in the official fields. Local account inventories, service capabilities, logging availability, and incident response procedures are required to turn this into an implementable detection plan.
Detection of Compromise Accounts
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 | T1586 | Compromise Accounts | This object detects Compromise Accounts. |
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 | 8f05066758f5… |
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 DET0876Open 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.