Detect Cloud Accounts in Google Chronicle
Adversaries may compromise cloud accounts to use during targeting operations. Compromised cloud accounts (Azure, AWS, GCP, Dropbox, OneDrive, GitHub) allow adversaries to leverage trusted third-party infrastructure for command and control, exfiltration to cloud storage, sending phishing or spam via cloud messaging services (AWS SES/SNS, SendGrid, Twilio), and acquiring additional cloud infrastructure without managing their own servers. Compromise methods include phishing for cloud credentials, password spraying, purchasing leaked credential sets from criminal markets, or stealing OAuth access tokens. APT29 has been observed using compromised Azure Virtual Machine accounts with residential proxies to obfuscate access to victim environments. This is a PRE-ATT&CK technique — the initial account compromise occurs outside the victim environment on third-party cloud platforms. Detection pivots to observable downstream effects: anomalous authentication events in cloud identity provider logs, risk signals from Identity Protection engines, MFA bypass indicators, and post-compromise behaviors such as bulk cloud storage access or cloud messaging API abuse.
MITRE ATT&CK
- Tactic
- Resource Development
- Technique
- T1586 Compromise Accounts
- Sub-technique
- T1586.003 Cloud Accounts
- Canonical reference
- https://attack.mitre.org/techniques/T1586/003/
YARA-L Detection Query
rule t1586_003_compromised_cloud_account_usage {
meta:
author = "Argus Detection Engineering"
description = "Detects compromised Azure cloud account usage via Identity Protection risk signals: high/medium risk sign-ins, confirmed compromise states, risky event categories (impossible travel, leaked credentials, password spray, anonymized IP, nation-state IP), and cross-tenant MFA bypass patterns in Azure AD sign-in logs."
mitre_attack_technique = "T1586.003"
mitre_attack_tactic = "Resource Development"
severity = "HIGH"
confidence = "HIGH"
rule_version = "1.0"
platform = "Azure Active Directory"
events:
$e.metadata.event_type = "USER_LOGIN"
$e.metadata.product_name = "Azure Active Directory"
$e.security_result.action = "ALLOW"
(
$e.security_result.severity = "HIGH" or
$e.security_result.severity = "MEDIUM" or
re.regex(
$e.security_result.category_details,
`(?i)(impossibleTravel|anonymizedIPAddress|maliciousIPAddress|unfamiliarFeatures|passwordSpray|leakedCredentials|nationStateIP|riskyIPAddress|investigationsThreatIntelligence|confirmedCompromised|atRisk)`
) or
(
$e.network.http.user_agent = "" and
re.regex($e.security_result.action_details, `(?i)singleFactor`) and
$e.principal.resource.attribute.labels["homeTenantId"] != $e.target.resource.attribute.labels["resourceTenantId"]
)
)
condition:
$e
}Chronicle YARA-L 2.0 rule detecting compromised Azure cloud account usage by matching USER_LOGIN events from Azure Active Directory with security_result severity HIGH or MEDIUM (mapped from riskLevelDuringSignIn by the Chronicle Azure AD parser), or category_details containing Identity Protection risk event type strings, or cross-tenant single-factor authentication bypass conditions. The security_result fields are populated by the Chronicle Azure AD ingestion parser from Azure Monitor sign-in log schema.
Data Sources
Required Tables
False Positives & Tuning
- High-profile executives or board members with persistent MEDIUM severity risk profiles due to frequent travel to multiple countries, causing continuous rule triggering that should be managed via allowlist or risk score tuning in Azure Identity Protection
- Newly provisioned accounts authenticating for the first time from corporate-issued devices triggering unfamiliarFeatures as HIGH severity before the Identity Protection engine has established a behavioural baseline for the account
- Chronicle parser version mismatches following Microsoft schema changes to the sign-in log format where risk_level fields are temporarily unmapped and default to empty strings, causing missed detections until the parser is updated
Other platforms for T1586.003
Testing Methodology
Validate this detection against 4 adversary techniques from Atomic Red Team. Each test below lists the behaviour to exercise and the telemetry you should expect to see. Executable commands and cleanup steps are available with Pro.
- Test 1Azure AD Password Spray Simulation
Expected signal: Azure AD SigninLogs: multiple ResultType != 0 (error code 50126: invalid credentials) entries from the same source IPAddress within a 5-10 minute window, each with a different UserPrincipalName. Azure Identity Protection will aggregate the spray pattern and generate a passwordSpray risk event type within 15-30 minutes of the spray completing, appearing in Azure AD > Security > Identity Protection > Risk Detections.
- Test 2Sign-In from Anonymizing Proxy to Trigger Identity Protection Risk Event
Expected signal: Azure AD SigninLogs: successful sign-in (ResultType=0) with IPAddress matching a known Tor exit node (verifiable against dan.me.uk/torlist or similar). RiskEventTypes_V2 populated with 'anonymizedIPAddress'. RiskLevelDuringSignIn set to 'medium' or 'high' within 5-15 minutes. The risk detection appears in Azure AD > Security > Identity Protection > Risk Detections with detectionTimingType='realtime' or 'nearRealtime'.
- Test 3OAuth Access Token Reuse for Cloud Storage Access
Expected signal: Azure Storage diagnostic logs (StorageBlobLogs): AuthenticationType='OAuth', RequesterObjectId matches the test user's object ID, URI shows container list and blob download operations. No new SigninLogs entry is generated since token reuse does not trigger interactive authentication. Defender for Cloud Apps (if deployed) generates an anomalous cloud storage access alert when detecting storage API access from an unusual user agent or IP without corresponding SigninLogs event.
- Test 4AWS Cloud Credential Validation and Reconnaissance
Expected signal: AWS CloudTrail events (sourcetype=aws:cloudtrail in Splunk): GetCallerIdentity (eventSource=sts.amazonaws.com), ListAttachedUserPolicies and ListGroupsForUser (eventSource=iam.amazonaws.com), ListBuckets (eventSource=s3.amazonaws.com), DescribeInstances (eventSource=ec2.amazonaws.com) — all sharing the same sourceIPAddress, userAgent (aws-cli/<version>), and accessKeyId within a 2-minute window. If AWS GuardDuty is enabled, Recon:IAMUser/MaliciousIPCaller or Recon:IAMUser/PortProbeUnprotectedPort findings may fire depending on source IP reputation.
References (10)
- https://attack.mitre.org/techniques/T1586/003/
- https://unit42.paloaltonetworks.com/compromised-cloud-compute-credentials/
- https://awakesecurity.com/blog/threat-hunting-series-detecting-command-control-in-the-cloud/
- https://www.netcraft.com/blog/popular-email-platform-used-to-impersonate-itself/
- https://www.microsoft.com/security/blog/2021/10/25/nobelium-targeting-delegated-administrative-privileges-to-facilitate-broader-attacks/
- https://learn.microsoft.com/en-us/azure/active-directory/identity-protection/concept-identity-protection-risks
- https://learn.microsoft.com/en-us/azure/active-directory/reports-monitoring/reference-azure-monitor-sign-ins-log-schema
- https://learn.microsoft.com/en-us/microsoft-365/security/defender/advanced-hunting-emailevents-table
- https://docs.splunk.com/Documentation/AddOns/released/MSCloudServices/ConfigureInputs
- https://mandiant.com/resources/blog/apt29-microsoft-365
Unlock Pro Content
Get the full detection package for T1586.003 including response playbook, investigation guide, and atomic red team tests.