T1078.004 Cloud Accounts - a place in kill chainand why SOC stalls
T1078.004 (CloudAccounts) in MITRE AT&CK covers four tactics at once: InitialAccess, Persistence, Privilege Escalation and Defense Evasion.Atypical situation - one technique closes the attacker several stagesat the same time. Received Valid cloud credentials - enteredWednesday, entrenched, raised privileges. And all this looks likelegitimate activity.
Here’s the mainSOC pain: API calls with valid credentials are indistinguishable fromthe actions of a real user without a behavioral baseline. Red Canaryrecords that the bulk of the detectives T1078.004 falls on the leginestage - an abnormal source, an atypical user agent, a non-complianceof geolocation. After successful authentication, the detectionbecomes sharply complicated because the attacker works through theregular APIs and consoles. In fact, it becomes a “legitimate user”.
A typical chainwhen compromising a cloud account:
1. InitialAccess - phishing, Key Leak, SSRF to IMDS, social engineeringhelpdesk
2. Discovery -searchable APIs, reading IAM-politics, enumeration repositories
3. PrivilegeEscalation - PassRole, AssumReole, Credentials
4. Persistence- backdoor accounts, change federations, malware OAuth applications
5. Impact -exfiltration through native storage services, backup encryption viaAPI, start cryptomining
According toRecorded Future (2025), the attackers are increasingly using thebuilt-in capabilities of cloud platforms for post-exploitation:native storage services for exfiltration, CI/CD-PIlines forintroducing code, calendar services as C2 channels. A separate trendis the targeting of LLM and AI services in the cloud aftercompromising the account: attackers rent GPU resources of the victimor get access to proprietary models. That is, even if you are notusing AI - the attacker can start using your power at your expense.
Decision tree:which line vector to wait for
Azure
iscomparation of identity plane and detectionPrincipal Service,and OAuth-Texods
According toRecorded Future (2025), attacks on cloud accounts in Azureenvironments hit three areas:
Compromise ofService Principals. Principal Service - identity for applications andautomation. If the application with permissionsDirectory.ReadWrite.All compromised, the attacker gains control oftenant. Unlike user accounts, Service Principals is often not coveredby MFA and Conditional Access. This is a blind spot that SOC teamsare regularly missed – simply because Service Principals don’tshow up in standard dashboards next to “live” users.
Manipulation.Federation Recorded Future fixes: attackers change the settings ofthe federation, abuse sync accounts, counterfeit tokens or createbackdoor-identity for the impersonality of users with a completebypass of the MFA. Direct analogue of the golden SAML / golden ticketfrom on-prem AD, only in the cloud.
OAuth appregistration. Creating a malicious application from permissions toread mail, files, or management of the route - a route thatexperiences a change in the password of the compromised user. Theattacker seeks an enydon grant from the user with sufficientprivileges - and then the application works autonomously. Thepassword was changed, MFA was re-released, and the maliciousapplication continues to pull the data.
Applicability:external pentest (through phishing consent grant), internal (throughcompromise of Global Admin or Application Admin).
Detection viaAzure AD Logs and Sigma rule
Sigma-rules fromSigmaHQ for Azure environments:
• azure_tap_added.yml-detects the addition of Temporary Access Pass (TAP). TAP is analternative authentication method that the attacker adds to bypassMFA after compromising the admin account
• azure_mfa_interrupted.yml-interrupted MFA queries; mass interruptions indicate MFA audit attack
• azure_mfa_denies.yml-multiple MFA failures followed by a successful login = suspicion ofSIM swap or intelligentation method compromising
•okta_new_behaviours_admin_console.yml- if Okta isused as IdP, the rule catches new behavioral patterns when accessingan admin console
Correlation rulefor Azure: Adding TAP → registration of a new device in Azure ADwithin 24 hours → login without MFA-challenge = Critical. This is atypical post-compromise persistence pattern that is passed through aphoto analysis. Each alternator is a medium. Three together in a dayis an incident.
Detectionchecklist for SOC: coating T1078.004
The minimum set ofdetectives, mandatory to cover attacks on cloud accounts:
According toD3FEND (MITRE), key countermeasures for T1078.004: D3-AM (AccessModeling) - building a normal access model, D3-AA (AgentAuthentication) - enhanced authentication, D3-AL (Account Locking) -automatic blocking for anomalies. Foundation - baseline normalbehavior (NIST CSF 2.0, DE.AE-01), without which detects generatenoise instead of actionable alerts.
Fororganizations-subjects of the CII, the disprocket of a cloud accountwith access to significant objects starts the duties of notifyingFSTEC according to FZ-187 (Article 14) - supervision through plannedand unscheduled inspections.
Trade-off ofprotective measures: what covers and where blind areas
According toAbnormal Security, 63% of security leaders skeptically rate MFA as anprotection against account gainover, and 65% by SSO. Skepticism isjustified: MFA closes the category of attacks (credential stuffing,password spray), but not AiTM session, hijacking or abuse of OAuthtokens. At the same time, 87% of organizations expect nativeprotection against ATO by the cloud provider. But providers are notsecurity companies, and their built-in mechanisms are sharpened forprotection against misconfiguration, and not under real-timedetection of the commute to a cloud account.
On several redteam projects in 2024, I saw the same picture: the organizationincluded MFA for all users, configured Conditional Access, connectedGuardDuty - and at the same time had not a single correlation rulethat would link cloud events into the chain. Separate alerts onConsoleLogin There were an unusual geolocation. CorrelationConsoleLogin → → CreateAccessKey → → RunInstances with aGPU-type in 60 minutes - absent. The result: the cryptominingcampaign worked for three days until the account came from AWS.
The root problemis not in the tools. CloudTrail, Azure AD Logs, GuardDuty, Defenderfor Cloud - all generate events. The problem is the lack ofcloud-specific SOC-playbooks that describe not “more to monitor”but “what to do when you see the sequence A → B → C in Nminutes.”
