Acquire Infrastructure: Web Services (T1583.006) belongs to the resource development tactic and is marked PRE, meaning it happens before the target is touched.
The adversary signs up for an ordinary web service, the kind your own staff use every day. That is what makes it hard to see.
How attackers use it
MITRE says adversaries register for web services that they abuse later in the lifecycle. The technique page names three follow-on uses: command and control through a web service, exfiltration over a web service, and phishing.
Popular providers help them. MITRE gives Google, GitHub and Twitter as examples of services that let adversaries hide in expected noise. Because the account is registered by the adversary, it is also hard to tie operations back to a person.
Note the difference from its sibling, Compromise Accounts. Here the adversary creates the account. They are not taking over yours.
How to detect it
The MITRE detection text makes two points.
First, once an adversary uses the web service as infrastructure, it may be possible to look for unique characteristics of adversary software, if those are known. That means indicators you already hold from threat reporting, such as how a particular implant talks to a particular service.
Second, much of the activity takes place outside the visibility of the target organization. Detection effort is better spent on the related stages: Command and Control through Web Service, and Exfiltration Over Web Service.
Practical signals to look for in proxy or DNS logs, as a general approach:
- Hosts that contact a consumer web service that no business process requires.
- Non-browser processes making regular, small requests to a code hosting or document sharing domain.
- Large uploads to a personal account on a service your company sanctions only for corporate accounts.
How to reduce the risk
MITRE's only mitigation entry is Pre-compromise. Preventive controls cannot easily stop an adversary from signing up for a public service.
What you control is how your own network treats those services. This is general practice.
- Decide which web services employees may reach and which accounts are allowed. Tenant restrictions, where a provider offers them, help separate corporate from personal accounts.
- Alert on non-browser software that talks to services it has no reason to use.
- Keep a list of indicators from threat reports and check your proxy logs against it on a schedule.
One more habit is worth adding: write down which web services your organization has approved for each purpose, such as code hosting, file sharing and messaging. Once that list exists, traffic to a service outside it becomes a question you can ask, not a guess. Review the list twice a year, because services come and go and teams adopt new ones without telling anyone.
Check your own environment
- Pull a week of proxy or DNS logs and list the top domains contacted by servers, not workstations. Servers rarely need consumer web services.
- Check which processes, other than browsers, reach code hosting, file sharing and messaging domains.
- Confirm that outbound uploads to cloud storage are logged with user and byte counts.
- On Linux, a read-only look at established outbound connections by process:
ss -tpn state established(iproute2).
Quick check
Does the adversary compromise an account in T1583.006?
No. They register a new account. Taking over an existing account is the sibling technique, Compromise Accounts: Web Services.
Where does MITRE suggest focusing detection?
On related stages such as Command and Control over a web service and Exfiltration Over Web Service, since the registration itself is outside your visibility.
