Compromise Accounts (T1586) is a resource development technique tagged PRE. It has three sub-techniques: Social Media Accounts, Email Accounts and Cloud Accounts.
It is the other half of the account pair. Establish Accounts builds a new identity. Compromise Accounts takes over one that already exists, with its history and relationships.
The result is trust that was not earned. A message from a colleague, a partner or a known service is far more likely to be read.
How attackers use it
MITRE says that rather than creating and cultivating accounts, adversaries may compromise existing ones. An existing persona can create a level of trust in a potential victim, if the victim has a relationship with, or knowledge of, that persona.
MITRE lists several ways accounts get compromised:
- Gathering credentials through phishing for information.
- Purchasing credentials from third-party sites.
- Brute forcing credentials, for example through password reuse from breach credential dumps.
- Paying employees, suppliers or business partners for access to credentials.
Before compromising an account, adversaries may do reconnaissance to decide which accounts to take. Personas may exist on one site or on several, such as Facebook, LinkedIn, Twitter and Google. A compromised account may need extra development, such as editing profile information, growing a social network or adding photos.
Email accounts can be used directly for phishing for information or phishing. The sub-technique pages add that a compromised email account can hijack existing threads, that a compromised social media profile can hijack connections to targets, and that compromised cloud accounts can supply storage, compute and messaging services.
A point for defenders: the owner of the account is a victim before anyone else is. Treat a report that your account sent something strange as a compromise until shown otherwise.
How to detect it
MITRE offers two kinds of detection suggestions.
For accounts connected to your organization:
- Consider monitoring social media activity related to your organization. Suspicious activity may include personas that claim to work for your organization, or recently modified accounts that make numerous connection requests to accounts affiliated with your organization.
- Because much of this activity is outside your visibility, detection efforts may be focused on related stages such as initial access through phishing.
For network and host signals, MITRE lists:
- Traffic analysis and packet inspection for protocols that do not follow expected standards and traffic flows, with TLS inspection for encrypted traffic where it is appropriate.
- Correlation with process monitoring and command lines to find anomalous process execution and arguments that relate to traffic patterns.
General practice for the accounts you own:
- Review sign-in logs for logins from new locations and devices, impossible travel and repeated failures across many accounts at once.
- Alert on new mail forwarding rules, new OAuth app grants and changes to recovery information.
- Check for your users' credentials in breach data and force a reset when found.
- Treat a spike in password reset requests as a signal.
Partners matter too. If a supplier's account is compromised, their email to you is the vector. Mail from known senders that is unusual in tone, timing or content deserves a second look, and a quick call to a known number settles it.
How to reduce the risk
MITRE lists Pre-compromise as the mitigation: preventive controls cannot easily stop behavior outside enterprise defenses. You cannot prevent someone else's account from being compromised, but you can protect your own and limit the damage of someone else's.
- Require multi-factor authentication for every account, with phishing resistant methods for administrators and high-risk roles.
- Do not reuse passwords. MITRE names password reuse from breach dumps as a path. A password manager makes unique passwords practical.
- Monitor for leaked credentials of your domain and reset them.
- Review partner and supplier access, and require the same account hygiene from them in contracts.
- Teach staff to verify unexpected requests, especially those about payment, access or credentials, through a second channel.
- Have a plan for when a staff account is hijacked: reset, revoke tokens, review rules, notify contacts.
- Remove unused accounts. A dormant account is a gift.
Developer accounts deserve special mention. A hijacked maintainer account on a code host or registry can push a malicious update that reaches many downstream users. Keeping a list of the packages you rely on, and watching for new versions, is a practical safeguard. Safeguard offers a free in-browser dependency scan at https://gold.safeguard.sh/scan, with no login, the file staying on your machine and a limit of 100 dependencies.
A quick way to turn this into work is a table with three columns: the account type, the owner and the recovery plan.
Email accounts: owner is IT. Plan is to reset the password, revoke sessions and app grants, remove forwarding rules and notify contacts who received odd messages.
Social media accounts: owner is communications. Plan is to regain access through the platform, remove unknown posts and connections, and tell followers.
Cloud accounts: owner is the cloud team. Plan is to disable keys, rotate secrets, review new resources and billing, and check logs for changes to roles.
Fill it in and run a tabletop around one row. The conversation will surface who holds the recovery phone number, where the backup codes are stored and who is allowed to speak for the company. Those answers are far cheaper to find in a meeting than during an incident.
Remember the supplier angle too. A message from a partner whose account was taken will pass many filters. A call-back habit for money and access requests is a control that works regardless of how good the forgery is.
Check your own environment
- Is multi-factor authentication required for all staff, and for all admin accounts using a stronger method?
- Do you check breach data for your domain on a schedule?
- Can you list all mail forwarding rules and OAuth app grants across your tenant?
- Do you have a documented response for a hijacked account?
- Which partners can send mail that your staff would trust without question?
- Windows, PowerShell, read-only:
Get-LocalUser | Select Name,Enabled,LastLogonlists local accounts and last logon times, a quick way to find dormant ones.
Quick check
How do compromised accounts differ from established ones?
They are existing accounts with history and relationships, so they carry trust that a new account would not.
Name two ways MITRE says accounts are compromised.
Phishing for credentials and purchasing credentials from third-party sites. Brute forcing through password reuse and paying insiders are also listed.
What should you assume if your account sent something odd?
Assume it was compromised. Reset it, revoke sessions, check rules and notify contacts.
