MITRE ATT&CK T1586 Compromise Accounts Guide: Detecting Use of Hijacked Accounts

MITRE ATT&CK T1586 Compromise Accounts describes adversaries taking over existing email, social media and cloud accounts so they can use a trusted identity against someone else. It sits in the Resource Development tactic (TA0042), which means most of the activity happens before the attack reaches the real target, and often in an organisation that is not the final victim at all. The defensive problem therefore has two halves: stopping your own accounts from becoming an adversary's resource, and spotting when a trusted partner's hijacked account is being used against you. This guide explains how the technique and its three sub-techniques work, where it shows up, what you can realistically detect and what prevents it. It is written for SOC analysts, detection engineers, identity teams and email security owners.

Key takeaways

• T1586 is about reuse of trust, not initial access. The adversary compromises an account so that messages, files or infrastructure from it look legitimate; using the account to get into its owner's own environment is T1078 Valid Accounts.
• Three sub-techniques in ATT&CK v20: T1586.001 Social Media Accounts, T1586.002 Email Accounts and T1586.003 Cloud Accounts. Email accounts carry by far the most procedure examples.
• MITRE says it cannot be easily prevented directly. The only mapped mitigation is M1056 Pre-compromise, so practical defence moves to the stages either side: protecting your accounts from takeover, and inspecting inbound activity from accounts you already trust.
• Your own hijacked mailbox is someone else's T1586. Inbox forwarding rules, hiding rules, unusual sending volume and new MFA methods on a mailbox are the strongest signals inside your own tenant.
• Developer and cloud accounts are now part of the picture. Hijacked GitHub, package registry and cloud storage accounts are used to push malicious code and host tools, so these identities need the same protection as email.

How the attack works

ATT&CK defines Compromise Accounts as adversaries compromising "accounts with services that can be used during targeting", as an alternative to creating new accounts (T1585 Establish Accounts). An existing persona brings history, connections and reputation that a fresh account lacks. The technique follows a broadly consistent lifecycle.

1. Select: reconnaissance identifies accounts whose identity will be trusted by the real target, such as a supplier's accounts payable mailbox, a journalist's social profile, or a maintainer of a popular open source package.
2. Acquire credentials: ATT&CK lists phishing for credentials (T1598 Phishing for Information), buying credentials from third-party sites, brute forcing using password reuse from breach dumps, and paying employees, suppliers or business partners for access. LAPSUS$ is recorded paying insiders for credentials.
3. Take over and develop: the adversary signs in, may add its own MFA method or forwarding, and may adjust the profile so the persona fits the operation.
4. Use against the target: sending phishing from the trusted address, hijacking existing email threads, connecting to targets on social platforms, or using cloud storage and messaging services as attack infrastructure.

The three sub-techniques

The cloud sub-technique explicitly includes messaging platforms such as Twilio, SendGrid, AWS SNS and AWS SES being abused for spam and phishing, and notes that adversaries may target privileged service provider accounts to exploit a T1199 Trusted Relationship with the provider's customers.

How T1586 differs from neighbouring techniques

The same takeover can map to several of these depending on whose perspective you take. When your finance mailbox is hijacked and used to invoice a customer, your incident is T1078 and T1114.003 Email Forwarding Rule, and your customer's incident starts with T1586.002. See the MITRE ATT&CK T1078 Valid Accounts Guide.

Where it shows up

• Business email compromise and supplier fraud: the FBI's IC3 public service announcement of September 2024 reports 305,033 BEC incidents and USD 55.5 billion in exposed losses worldwide between October 2013 and December 2023, and describes attackers compromising legitimate business or personal email accounts to make unauthorised transfers. A hijacked supplier mailbox replying in an existing invoice thread is the classic case. See the Business Email Compromise Response Playbook.
• Espionage phishing: state-linked groups such as Star Blizzard and APT29 use compromised accounts to phish the original victim's contacts, so a message arrives from someone the target already knows.
• Developer platforms: compromised GitHub and package registry accounts let attackers publish code under a trusted name. In the GhostAction campaign, push access to maintainer accounts was used to commit a disguised workflow to 817 repositories that exfiltrated about 3,325 CI/CD secrets.
• Cloud infrastructure: compromised storage and messaging accounts host payloads and send phishing from reputable sender domains, which weakens reputation-based filtering.
• Social platforms: hijacked executive or brand accounts are used for scams and for reaching staff. See the Disinformation and Brand Impersonation Guide.

Impact

The damage lands in two places. The account owner suffers data exposure, reputational harm and possibly liability when its systems were used to defraud partners. The final target suffers whatever the borrowed trust enabled: a fraudulent payment, a malware infection, stolen credentials or a poisoned software dependency. Because messages come from a real, authenticated sender, SPF, DKIM and DMARC all pass, and link and attachment reputation checks may pass too. Thread hijacking also removes the usual social engineering tells, since the conversation, signatures and timing are genuine. For developer accounts, a single hijacked identity can push malicious code to every downstream consumer, which the Shai-Hulud npm worm showed when stolen publishing tokens were used to republish victims' own packages. For the wider set of threats this feeds, see our top 10 email security threats.

Detection

MITRE's detection strategies for T1586 (DET0876, with DET0861, DET0870 and DET0879 for the sub-techniques) all note that much of this activity "will take place outside the visibility of the target organization". Detection therefore splits into three places: your own accounts being taken over, your accounts being used as a resource, and inbound activity from trusted accounts.

Signals inside your own tenant

The symptoms Microsoft lists for a compromised mailbox are a useful hunting checklist: suspicious messages in Sent Items or Deleted Items, changes to the user's Global Address List entry, recently added external forwarding, unexplained lockouts and odd email signatures.

Signals on inbound activity

• Thread hijack indicators: a reply in an existing thread that changes payment details, adds an unexpected link or attachment, or arrives from a new reply-to address or client.
• First-seen behaviour from known senders: a long-standing correspondent suddenly sending file-sharing links, archive attachments or QR codes.
• Supplier change requests: any request to change bank details, treated as a high-risk event regardless of how authentic the sender looks.
• Social platform approaches: MITRE's analytic suggests watching for personas claiming to work for your organisation and recently modified accounts making many connection requests to your staff.
• User reports: make reporting easy and route reports from finance and executive assistants for fast triage. See the Email Security Guide.

Metrics

• Time from a suspicious inbox forwarding detection to rule removal and session revocation.
• Percentage of mailboxes and developer accounts protected by phishing-resistant MFA.
• Number of external forwarding rules in the tenant, trending to zero outside approved exceptions.
• Percentage of supplier bank detail changes verified out of band before payment.
• Number of leaked credential detections closed with a password reset and session revocation within 24 hours.

Prevention and hardening

Because ATT&CK maps only M1056 Pre-compromise to T1586, prevention means making your own accounts poor resources and making borrowed trust less useful against you.

Rolling out the controls

1. Inventory exposure first: export all inbox rules and mailbox forwarding settings, and list accounts without MFA or with only SMS or voice MFA.
2. Turn on detections in report mode: enable inbox forwarding, inbox manipulation and sending pattern detections, and route them to the SOC without automated blocking for two weeks to tune.
3. Block external forwarding: apply to a pilot group, collect exceptions, then enforce tenant-wide. Roll back by re-enabling forwarding for named mailboxes, not the whole tenant.
4. Phishing-resistant MFA in rings: administrators and finance first, then executives and their assistants, then developers with publishing rights, then everyone.
5. Automate response: on a confirmed hijack, disable or reset the account, revoke sessions and refresh tokens, review MFA methods, consented apps, roles and forwarding, and notify contacts who received messages from it.
6. Close the loop with suppliers: agree verification procedures and a contact route for reporting suspected compromise in both directions.

Small organisations get most value from phishing-resistant MFA on email, blocking external forwarding and a firm callback rule for payment changes. Large organisations should add ITDR-style correlation of identity risk with mail flow and developer platform logs. See the ITDR Guide.

Framework mapping

Lessons from incidents

• Developer accounts are trusted senders too: in GhostAction the compromised accounts' existing push rights meant the malicious workflow needed no exploit. Protect maintainer accounts with phishing-resistant MFA and review workflow changes.
• Every hijacked account becomes a launch point: the Shai-Hulud worm turned each compromised maintainer into a new source of infection, the defining T1586 pattern at scale.
• Do not trust the address, verify the request: BEC losses reported by IC3 depend on genuine mailboxes being believed. Out-of-band verification breaks the chain even when every technical check passes.
• Clean up everything the adversary added: forwarding rules, hidden inbox rules, MFA methods and consented apps survive a password reset. Microsoft's compromised account procedure covers each one.

Practitioner checklist

• Export and review every inbox rule (including hidden) and mailbox forwarding setting; remove unapproved external forwarding.
• Block external auto-forwarding by default with documented exceptions.
• Enforce phishing-resistant MFA for administrators, finance, executives and developers with publishing rights.
• Alert on suspicious inbox forwarding, inbox manipulation rules, suspicious sending patterns and suspicious credential addition.
• Disable dormant accounts and monitor for leaked credentials.
• Require out-of-band verification for all supplier bank detail changes and unusual payment requests.
• Write a hijacked account runbook: disable, reset, revoke sessions, review MFA methods, apps, roles and rules, notify recipients.
• Agree compromise notification routes with key suppliers and customers.
• Map the coverage in your ATT&CK heatmap honestly: T1586 is detected mostly through its neighbours. See the MITRE ATT&CK Coverage Mapping Guide.

Standards and references

• MITRE ATT&CK: Compromise Accounts (T1586)
• MITRE ATT&CK: Compromise Accounts: Email Accounts (T1586.002)
• MITRE ATT&CK: Compromise Accounts: Cloud Accounts (T1586.003)
• FBI IC3: Business Email Compromise: The $55 Billion Scam
• CISA: Implementing Phishing-Resistant MFA
• Microsoft Learn: Responding to a compromised email account
• Microsoft Learn: What are risk detections?
• NIST: SP 800-53 Rev. 5

Related NHI Mgmt Group resources: MITRE ATT&CK Guide for Defenders · Account Takeover Prevention Guide · MITRE ATT&CK T1528 Steal Application Access Token Guide · Phishing Guide