Has used valid cloud accounts to gain initial access or to escalate privileges within cloud environments.1 Additionally, ShinyHunters has also used valid credentials from public repositories to include access keys to gain access to the victim organization’s AWS environment.23
- Tactics
- Initial Access, Persistence, Privilege Escalation, Stealth
- Platforms
- IaaS, Identity Provider, Office Suite, SaaS
- Version
- 2.0
- Created
- 13 March 2020
- Last modified
- 12 May 2026
- Contributors
- Alon Klayman, Hunters Security; Arun Seelagan, CISA; Eliraz Levi, Hunters Security; Jon Sternstein, Stern Security
Valid accounts in cloud environments may allow adversaries to perform actions to achieve Initial Access, Persistence, Privilege Escalation, or Defense Evasion. Cloud accounts are those created and configured by an organization for use by users, remote support, services, or for administration of resources within a cloud service provider or SaaS application. Cloud Accounts can exist solely in the cloud; alternatively, they may be hybrid-joined between on-premises systems and the cloud through syncing or federation with other identity sources such as Windows Active Directory.[1][2][3]
Cloud Accounts MITRE reference T1078.004
12 groups have been recorded using this technique. Newest first; each entry carries MITRE’s procedure text and a link to the group’s full record. Click a name to filter the rules below.
Has used compromised credentials for GitHub and software package repositories, including privileged service accounts, to inject malicious code into CI/CD pipelines.123456778
Has leveraged privileged cloud accounts to access cloud-based management consoles to include Microsoft Intune.1 VOID MANTICORE has also compromised existing accounts within the Microsoft Entra ID environment.2
Has leveraged compromised accounts to access Microsoft Entra Connect, which was used to synchronize on-premises identities and Microsoft Entra identities, allowing users to sign into both environments with the same password.1 Storm-0501 has also used the victim Global Administrator account that lacked any registered MFA method to access victim cloud environments.2 Storm-0501 has leveraged Storage Account Access Keys within the victim environment.2
Has accessed Microsoft M365 cloud environments using stolen credentials. 1
Has used compromised Microsoft Entra ID accounts to pivot in victim environments.1
All 12 groups for this technique · 6 newest in this preview
3 campaigns have been recorded using this technique. Listed newest first; dates are year-granularity and attribution is MITRE’s.
During the 2025 Poland Wiper Attacks, the adversaries leveraged stolen credentials from on-premises environments to access cloud services.1
During C0027, Scattered Spider leveraged compromised credentials from victim users to authenticate to Azure tenants.1
During the SolarWinds Compromise, APT29 used a compromised O365 administrator account to create a new Service Principal.1
All 3 campaigns for this technique
6 software entries are documented implementing this technique. MITRE files each as a tool or as malware; newest first, then by how many groups carry them.
Has used compromised accounts for Docker Hub and GitHub to publish malicious software packages.1
Has used stolen credentials to log into cloud services to access cloud hosted repositories and other cloud storage solutions to discover sensitive data to include API Keys, tokens and credentials.1
Has leveraged compromised accounts to log into cloud services to access cloud hosted repositories.12345
Leverages valid cloud accounts to perform most of its operations.1
Leverages valid cloud credentials to perform enumeration operations using the internal Azure AD Graph API.1
Can use stolen service account tokens to perform its operations.1
All 6 software entries for this technique
Offense vs defense T1078.004
Is defensive coverage keeping up with adversary use? Eight counts, each ranked against all 697 ATT&CK techniques. Attack sits left, defense right, so a shape leaning left means adversaries are better documented here than defenders are equipped. Hover any spoke for its percentile and the share of techniques that have more. The timeline below shows when each side arrived.
How it got here
Adversary activity (campaign spans) over cumulative rule output. Each source is plotted independently from zero, so neither line includes the other. Campaign dates are year-granularity.
Cloud Accounts detection strategy DET0546
MITRE names one behaviour worth catching for this technique and breaks it into 4 analytics, one per platform. Each carries the log sources it needs and the fields you tune per environment.
Detection of Abused or Compromised Cloud Accounts for Access and Persistence
AN1503 · Identity Provider
Detects anomalous authentication activity such as sign-ins from impossible geolocations or legacy protocols from high-privileged accounts.
Log sources
The data this analytic draws on. You do not need every component — each one you already collect covers part of it. Each links to its ATT&CK record.
| Data component | Name | Channel |
|---|---|---|
| User Account AuthenticationDC0002 | azure:signinlogs | Sign-in activity |
| Logon Session MetadataDC0088 | saas:okta | user.authentication.sso |
Tunable fields
MITRE calls these the analytic’s mutable elements: the thresholds and filters you set for your own environment.
| Field | What you tune |
|---|---|
| AnomalousLocationThreshold | Defines geographic separation (e.g., impossible travel) considered suspicious. |
| ProtocolType | Filter based on legacy or deprecated authentication mechanisms. |
AN1504 · IaaS
Detects cloud account use for API calls that exceed normal scope, such as IAM changes or access to services never used before.
Log sources
The data this analytic draws on. You do not need every component — each one you already collect covers part of it. Each links to its ATT&CK record.
| Data component | Name | Channel |
|---|---|---|
| User Account AuthenticationDC0002 | AWS:CloudTrail | ConsoleLogin, AssumeRole, ListAccessKeys, CreateUser |
| Logon Session CreationDC0067 | gcp:audit | admin.googleapis.com |
Tunable fields
MITRE calls these the analytic’s mutable elements: the thresholds and filters you set for your own environment.
| Field | What you tune |
|---|---|
| ServiceInteractionBaseline | Custom list of expected service interactions per user or role. |
| RoleSwitchRateThreshold | Frequency of assume-role operations that triggers an alert. |
AN1505 · SaaS
Detects unexpected access or usage of cloud productivity tools (e.g., downloading large numbers of files, creating external shares) by internal users.
Log sources
The data this analytic draws on. You do not need every component — each one you already collect covers part of it. Each links to its ATT&CK record.
| Data component | Name | Channel |
|---|---|---|
| User Account AuthenticationDC0002 | gcp:audit | drive.activity |
| Logon Session MetadataDC0088 | m365:unified | FileAccessed, SharingSet |
Tunable fields
MITRE calls these the analytic’s mutable elements: the thresholds and filters you set for your own environment.
| Field | What you tune |
|---|---|
| FileDownloadThreshold | Defines excessive access based on number or size of downloads. |
| SharingPolicyViolationThreshold | Defines external sharing behaviors that violate policy. |
AN1506 · Office Suite
Detects login and usage patterns deviating from typical Microsoft 365 or Google Workspace user profiles.
Log sources
The data this analytic draws on. You do not need every component — each one you already collect covers part of it. Each links to its ATT&CK record.
| Data component | Name | Channel |
|---|---|---|
| User Account AuthenticationDC0002 | gcp:audit | login.event |
| Logon Session MetadataDC0088 | m365:signinlogs | UserLogin |
Tunable fields
MITRE calls these the analytic’s mutable elements: the thresholds and filters you set for your own environment.
| Field | What you tune |
|---|---|
| BusinessHours | Used to identify logins outside of expected work times. |
| OfficeProductivityToolBaseline | Defines expected application usage per department or role. |
Use conditional access policies to block logins from non-compliant devices or from outside defined organization IP ranges.
Disable legacy authentication, which does not support MFA, and require the use of modern authentication protocols instead.
Use multi-factor authentication for cloud accounts, especially privileged accounts. This can be implemented in a variety of forms (e.g. hardware, virtual, SMS), and can also be audited using administrative reporting features.
Ensure that cloud accounts, particularly privileged accounts, have complex, unique passwords across all systems on the network. Passwords and access keys should be rotated regularly. This limits the amount of time credentials can be used to access resources if a credential is compromised without your knowledge. Cloud service providers may track access key age to help audit and identify keys that may need to be rotated.
Review privileged cloud account permission levels routinely to look for those that could allow an adversary to gain wide access, such as Global Administrator and Privileged Role Administrator in Azure AD. These reviews should also check if new privileged cloud accounts have been created that were not authorized. For example, in Azure AD environments configure alerts to notify when accounts have gone many days without using privileged roles, as these roles may be able to be removed. Consider using temporary, just-in-time (JIT) privileged access to Azure AD resources rather than permanently assigning privileged roles.
Periodically review user accounts and remove those that are inactive or unnecessary. Limit the ability for user accounts to create additional accounts.
Applications may send push notifications to verify a login as a form of multi-factor authentication (MFA). Train users to only accept valid push notifications and to report suspicious push notifications.
Tests from Atomic Red Team (MIT licence) · technique definition