T1586: Compromise Accounts
Adversaries may compromise accounts with services that can be used during targeting. For operations incorporating social engineering, the utilization of an online persona may be important. Rather than creating and cultivating accounts (i.e. Establish Accounts), adversaries may compromise existing accounts. Utilizing an existing persona may engender a level of trust in a potential victim if they have a relationship, or knowledge of, the compromised persona.
A variety of methods exist for compromising accounts, such as gathering credentials via Phishing for Information, purchasing credentials from third-party sites, brute forcing credentials (ex: password reuse from breach credential dumps), or paying employees, suppliers or business partners for access to credentials.[1][2] Prior to compromising accounts, adversaries may conduct Reconnaissance to inform decisions about which accounts to compromise to further their operation.
Personas may exist on a single site or across multiple sites (ex: Facebook, LinkedIn, Twitter, Google, etc.). Compromised accounts may require additional development, this could include filling out or modifying profile information, further developing social networks, or incorporating photos.
Adversaries may directly leverage compromised email accounts for Phishing for Information or Phishing.
Analyst context for executives and security teams
Compromise Accounts is a pre-attack resource development behavior: adversaries obtain existing email, social media, or cloud accounts so later outreach or infrastructure appears more trustworthy. For leaders, the issue is not only account takeover inside the enterprise; it is that trusted third-party, employee, partner, or public personas can be used before the visible intrusion begins, especially for phishing or information-gathering activity.
Executive priority
Prioritize this as a readiness and resilience question: can the organization recognize suspicious use of trusted personas before employees act on them? This affects phishing resistance, identity governance, cloud security, vendor/partner risk, incident response triage, and audit evidence around preventive controls. Because this technique sits in Resource Development on the PRE platform, many signals may occur outside traditional endpoint monitoring, so budget and control decisions should account for email, identity, cloud, and external account monitoring gaps.
Technical view
ATT&CK provides no official detection text for T1586, but the related DET0876 detection strategy indicates this behavior is expected to be detectable with the right evidence. SOC and detection teams should validate visibility around compromised-account use in the related sub-areas: social media accounts, email accounts, and cloud accounts. Investigation playbooks should connect suspicious trusted-persona activity to possible follow-on Phishing for Information, Phishing, use of cloud storage, tool upload, or acquisition of infrastructure where those relationships are present in the supplied ATT&CK context.
Likely telemetry
- Email security logs and message metadata for trusted-sender phishing or unusual account use
- Identity provider and authentication logs for abnormal login patterns, password reuse indicators, brute-force attempts, and impossible or unusual access patterns
- Cloud account audit logs for storage use, account creation, infrastructure acquisition, or unusual access by accounts used during targeting
- Social media or public-platform account alerts where available for compromised organizational or executive personas
- Help desk, user reports, and phishing-reporting submissions involving known employees, partners, suppliers, or business contacts
Detection direction
- Confirm whether DET0876-style logic is implemented or mapped in the local detection program, since ATT&CK does not provide native detection guidance for this technique.
- Tune detections around abnormal use of trusted accounts rather than only unknown senders; compromised personas may look legitimate to users and basic allow-listing controls.
- Correlate email, identity, and cloud telemetry because the supplied subtechniques include email, social media, and cloud accounts rather than a single platform source.
- Treat reports involving known contacts requesting credentials, information, file access, or unusual actions as higher-priority triage candidates.
- Review false positives carefully: legitimate travel, marketing/social media activity, partner communications, or cloud administration can resemble suspicious account use without context.
Mitigation priorities
- Use pre-compromise measures aligned to M1056: reduce exposed information and make adversary preparation harder before targeting begins.
- Strengthen identity controls for organizational accounts, especially email and cloud accounts, including credential hygiene and resistance to password reuse risks referenced by ATT&CK.
- Define response processes for compromised public, social, supplier, partner, and executive personas, not only internal user accounts.
- Improve user reporting and verification workflows for requests arriving from trusted but unusual personas.
- Maintain evidence for compliance and assurance: account protection policies, phishing reporting metrics, identity logs, and incident handling records.
Analyst notes and limits
This technique is materially important because it exploits trust before an intrusion is obvious. The most useful local analysis is to identify which trusted personas would create business disruption if abused: executives, finance, IT, help desk, cloud administrators, communications teams, suppliers, and business partners. Glexia would use this object to drive validation of identity telemetry, phishing triage, cloud auditability, and incident response decision points.
The supplied ATT&CK object has no official detection description and is scoped to PRE / Resource Development. Specific detection engineering depends on local email, identity, cloud, social media, and third-party telemetry. The provided mitigation relationship description is truncated, so mitigation guidance is limited to the supplied M1056 pre-compromise framing and the account types described in the object and subtechniques.
Compromise Accounts
Adversaries may compromise accounts with services that can be used during targeting. For operations incorporating social engineering, the utilization of an online persona may be important. Rather than creating and cultivating accounts (i.e. Establish Accounts), adversaries may compromise existing accounts. Utilizing an existing persona may engender a level of trust in a potential victim if they have a relationship, or knowledge of, the compromised persona.
A variety of methods exist for compromising accounts, such as gathering credentials via Phishing for Information, purchasing credentials from third-party sites, brute forcing credentials (ex: password reuse from breach credential dumps), or paying employees, suppliers or business partners for access to credentials.[1][2] Prior to compromising accounts, adversaries may conduct Reconnaissance to inform decisions about which accounts to compromise to further their operation.
Personas may exist on a single site or across multiple sites (ex: Facebook, LinkedIn, Twitter, Google, etc.). Compromised accounts may require additional development, this could include filling out or modifying profile information, further developing social networks, or incorporating photos.
Adversaries may directly leverage compromised email accounts for Phishing for Information or Phishing.
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.
Related techniques
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.003 | Cloud Accounts Sub-technique | Cloud Accounts subtechnique of this object. |
| Enterprise | T1586.002 | Email Accounts Sub-technique | Email Accounts subtechnique of this object. |
| Enterprise | T1586.001 | Social Media Accounts Sub-technique | Social Media Accounts subtechnique of this object. |
All related ATT&CK context
Mitigation direction
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.2 | Current bundle | 1690a0873648… |
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]
AnonHBGary
Bright, P. (2011, February 15). Anonymous speaks: the inside story of the HBGary hack. Retrieved March 9, 2017.
Open source URL -
[2]
Microsoft DEV-0537
Microsoft. (2022, March 22). DEV-0537 criminal actor targeting organizations for data exfiltration and destruction. Retrieved March 23, 2022.
Open source URL -
[3]
mitre-attack T1586Open 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.