Most organizations let people sign in to cloud consoles with the same identity they use on the corporate network. That convenience means a compromised on-premises account can become a compromised cloud account.
MITRE tracks this as Cloud Services, technique T1021.007, under Lateral Movement. The platforms listed are IaaS, Identity Provider, Office Suite and SaaS.
How attackers use it
The adversary logs into cloud services using valid accounts that are synchronized with, or federated to, on-premises identities. They can then do management actions or reach cloud-hosted resources as that user.
Access can come through the web console or through command line tools and cloud APIs. MITRE names Connect-AZAccount for Azure PowerShell, Connect-MgGraph for Microsoft Graph PowerShell and gcloud auth login for the Google Cloud CLI. In some cases an application access token works in place of a username and password, which makes the sign-in even less visible.
How to detect it
MITRE's strategy (DET0008) lists four patterns:
- A cloud login from an unusual location or user-agent string, followed by resource enumeration or changes to infrastructure.
- A federated login using SSO or an OAuth grant to the cloud control plane, followed by directory or permissions enumeration.
- A login to Microsoft 365 or Google Workspace from command line tools or unexpected source addresses, followed by mailbox or document access.
- Access to a third-party SaaS product with OAuth or API tokens after an initial compromise, followed by sensitive data access or configuration changes.
All four are the same shape: a login that is valid on paper, then behavior that does not match the person. Feed your identity provider logs and cloud audit logs into one place and compare logins to the usual pattern for each user.
How to reduce the risk
MITRE lists two mitigations.
- Use multi-factor authentication on cloud services whenever possible.
- Limit high-privileged accounts and keep them separate. Keep the number of highly privileged domain and cloud accounts small, and do not use them for day-to-day work. Make sure on-premises accounts have no privileged cloud permissions, and use isolated, cloud-only accounts to manage the cloud environment.
The second one cuts the bridge. If a stolen domain account carries no cloud admin rights, the federation path leads nowhere important.
Check your own environment
Run through this list with your cloud and identity administrators:
- Which on-premises accounts hold roles in the cloud control plane? The target answer is none.
- Do cloud administrators have a separate cloud-only account for admin work?
- Is MFA enforced for every cloud sign-in, including command line and API sign-ins?
- Are OAuth grants and application tokens reviewed, and are unused ones removed?
- Do your logs let you answer, for any admin, where and with what tool they last signed in?
Try it yourself
Click through it at your own pace, or open it full screen.
Quick check
Why is a federated login a lateral movement path?
The same identity works in both worlds. An attacker who holds a valid on-premises account can reuse it against the cloud control plane if that account is synchronized or federated.
What is the single most useful structural fix MITRE suggests?
Keep on-premises accounts free of privileged cloud permissions and use isolated, cloud-only accounts for managing the cloud environment.
Sources
- MITRE ATT&CK, Cloud Services (T1021.007)
