Compromise Infrastructure: Web Services (T1584.006) is a resource development technique tagged PRE. The adversary takes over a legitimate user's access to a web service and uses the service as infrastructure.
It is the stolen-account twin of Acquire Infrastructure: Web Services. There the adversary signs up. Here they borrow an account that already has a history.
How attackers use it
MITRE lists GitHub, Twitter, Dropbox, Google and SendGrid among the services that legitimate users register for and that adversaries may try to take over. The compromised access can then support command and control through a web service, exfiltration over a web service or phishing.
Two benefits are named. Common services make it easier to hide in expected noise, and stolen access makes it hard to tie the operation back to the adversary. MITRE adds that using compromised web-based email services may let adversaries exploit the trust associated with legitimate domains.
For you, the question is double. Could one of your service accounts be used this way, and would anyone notice if it were?
How to detect it
MITRE says that once adversaries use the abused service as infrastructure, it may be possible to look for unique characteristics associated with adversary software, if known. It also notes that much of the activity is outside the visibility of the target organization, and points to related stages: command and control through a web service and exfiltration over a web service.
On the account side, general practice includes:
- Review sign-in logs for the services you control, looking for logins from new locations or devices and for sudden changes in behavior.
- Watch for new API tokens, app authorizations and forwarding rules on accounts that rarely change.
- Alert on unusual sending volume from email platforms and transactional mail services that you own.
How to reduce the risk
MITRE's mitigation entry is Pre-compromise: no easy preventive control exists, since the behavior is outside enterprise defenses.
For the accounts you own, these general steps reduce the chance that your account becomes someone's infrastructure.
- Use strong multi-factor authentication on every account with a public presence or an API key.
- Rotate tokens and keys on a schedule, and remove ones that are no longer used.
- Give service accounts the smallest scope that works.
- Keep recovery email and phone details current and protected.
To make this concrete, picture a company that publishes a product newsletter through a third-party mailing service. If an adversary takes over the account, the messages go out under a trusted sender, to a trusted list, with valid authentication. Recipients have no reason to doubt them. The defense is on the account: multi-factor authentication, limited access, alerts for sending spikes and a plan for contacting subscribers if something goes wrong. Write the plan before you need it, including who may approve a public correction.
Check your own environment
- List the web services your company publishes through: code hosting, social media, mail sending, file sharing. Who owns each account?
- Check that each one has multi-factor authentication turned on.
- Review active API tokens and connected apps. Remove those without a known owner.
- Look at the last 30 days of sign-in activity for any location you do not recognize.
Quick check
What is the difference between T1584.006 and T1583.006?
In T1584.006 the adversary takes over an existing account. In T1583.006 they register a new one.
Which services does MITRE name as examples?
GitHub, Twitter, Dropbox, Google and SendGrid.
