Detection coverage in DCV across AWS, Azure and GCP for Valid Accounts: Cloud Accounts, plus the corresponding Sigma rules in the CloudSigma library. Source data refreshed 2026-04-24.
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.
Service or user accounts may be targeted by adversaries through Brute Force, Phishing, or various other means to gain access to the environment. Federated or synced accounts may be a pathway for the adversary to affect both on-premises systems and cloud environments - for example, by leveraging shared credentials to log onto Remote Services. High privileged cloud accounts, whether federated, synced, or cloud-only, may also allow pivoting to on-premises environments by leveraging SaaS-based Software Deployment Tools to run commands on hybrid-joined devices.
An adversary may create long lasting Additional Cloud Credentials on a compromised cloud account to maintain persistence in the environment. Such credentials may also be used to bypass security controls such as multi-factor authentication.
Cloud accounts may also be able to assume Temporary Elevated Cloud Access or other privileges through various means within the environment. Misconfigurations in role assignments or role assumption policies may allow an adversary to use these mechanisms to leverage permissions outside the intended scope of the account. Such over privileged accounts may be used to harvest sensitive data from online storage accounts and databases through Cloud API or other methods. For example, in Azure environments, adversaries may target Azure Managed Identities, which allow associated Azure resources to request access tokens. By compromising a resource with an attached Managed Identity, such as an Azure VM, adversaries may be able to Steal Application Access Tokens to move laterally across the cloud environment.
Platforms: IaaS, Identity Provider, Office Suite, SaaS.
DCV maps 121 detections across 3 cloud providers to T1078.004. Coverage by source:
| Source | Cloud | Findings mapped | Avg confidence |
|---|---|---|---|
| Microsoft Defender for Cloud | Azure | 31 | 0.90 |
| AWS Config Rules | AWS | 29 | 0.52 |
| AWS Security Hub | AWS | 18 | 0.86 |
| Azure Policy | Azure | 16 | 0.87 |
| GCP Security Command Center | GCP | 11 | 0.78 |
| Azure Regulatory Compliance | Azure | 8 | 0.94 |
| AWS GuardDuty | AWS | 4 | 0.85 |
| AWS Macie | AWS | 3 | 0.80 |
| GCP Chronicle | GCP | 1 | 0.85 |
CloudSigma ships 7 production-ready Sigma rules that detect T1078.004 across 7 platforms. Every rule below is validated against its source SIEM dialect before publication.
High-fidelity detection of T1078.004 requires correlation
across multiple events. For example, a credential-validation call
followed by a reconnaissance chain (List* /
Describe*) within a short window from an unfamiliar
source. A single-event Sigma rule on
GetCallerIdentity alone fires constantly on
legitimate CLI, SDK and CI/CD activity.
Where you have a specific advisory, vulnerability disclosure or blog post that exercises T1078.004-style abuse, CloudSigma can generate a starting-point rule from that input. You then deploy it in your SIEM and combine it with the SIEM's native correlation features (timeframe joins across users, source-IP anomalies, impossible-travel checks). For T1078.004 specifically the generated rule is rarely sufficient on its own; pair it with the SIEM-side correlation logic before enabling in production.