Azure Storage Account Keys Accessed by Privileged User

  1[metadata]
  2creation_date = "2025/09/23"
  3integration = ["azure"]
  4maturity = "production"
  5updated_date = "2025/09/23"
  6
  7[rule]
  8author = ["Elastic"]
  9description = """
 10Identifies unusual high-privileged access to Azure Storage Account keys by users with Owner, Contributor, or Storage
 11Account Contributor roles. This technique was observed in STORM-0501 ransomware campaigns where compromised identities
 12with high-privilege Azure RBAC roles retrieved access keys to perform unauthorized operations on Storage Accounts.
 13Microsoft recommends using Shared Access Signature (SAS) models instead of direct key access for improved security.
 14This rule detects when a user principal with high-privilege roles accesses storage keys for the first time in 7 days.
 15"""
 16from = "now-9m"
 17index = ["logs-azure.activitylogs-*"]
 18language = "kuery"
 19license = "Elastic License v2"
 20name = "Azure Storage Account Keys Accessed by Privileged User"
 21note = """## Triage and Analysis
 22
 23### Investigating Azure Storage Account Keys Accessed by Privileged User
 24
 25Azure Storage Account keys provide full administrative access to storage resources. While legitimate administrators may occasionally need to access these keys, Microsoft recommends using more granular access methods like Shared Access Signatures (SAS) or Azure AD authentication. This detection identifies when users with high-privilege roles (Owner, Contributor, Storage Account Contributor, or User Access Administrator) access storage account keys, particularly focusing on unusual patterns that may indicate compromise. This technique was notably observed in STORM-0501 ransomware campaigns where compromised identities retrieved keys for unauthorized storage operations.
 26
 27### Possible investigation steps
 28
 29- Review the `azure.activitylogs.identity.authorization.evidence.principal_id` to identify the specific user who accessed the storage account keys.
 30- Examine the `azure.resource.name` field to determine which storage account's keys were accessed and assess the sensitivity of data stored there.
 31- Check the `azure.activitylogs.identity.authorization.evidence.role` to confirm the user's assigned role and whether this level of access is justified for their job function.
 32- Investigate the timing and frequency of the key access event - multiple key retrievals in a short timeframe may indicate automated exfiltration attempts.
 33- Review the source IP address and geographic location of the access request to identify any anomalous access patterns or locations.
 34- Correlate this event with other activities by the same principal ID, looking for patterns such as permission escalations, unusual data access, or configuration changes.
 35- Check Azure AD sign-in logs for the user around the same timeframe to identify any suspicious authentication events or MFA bypasses.
 36- Examine subsequent storage account activities to determine if the retrieved keys were used for data access, modification, or exfiltration.
 37
 38### False positive analysis
 39
 40- DevOps and infrastructure teams may legitimately access storage keys during deployment or migration activities. Document these planned activities and consider creating exceptions for specific time windows.
 41- Emergency troubleshooting scenarios may require administrators to retrieve storage keys. Establish a process for documenting these emergency accesses and review them regularly.
 42- Automated backup or disaster recovery systems might use high-privilege service accounts that occasionally need key access. Consider using managed identities or service principals with more restricted permissions instead.
 43- Legacy applications that haven't been migrated to use SAS tokens or Azure AD authentication may still require key-based access. Plan to modernize these applications and track them as exceptions in the meantime.
 44- New storage account provisioning by administrators will often include initial key retrieval. Consider the age of the storage account when evaluating the risk level.
 45
 46### Response and remediation
 47
 48- Immediately rotate the storage account keys that were accessed using Azure Portal or Azure CLI.
 49- Review all recent activities on the affected storage account to identify any unauthorized data access, modification, or exfiltration attempts.
 50- If unauthorized access is confirmed, disable the compromised user account and initiate password reset procedures.
 51- Audit all storage accounts accessible by the compromised identity and rotate keys for any accounts that may have been accessed.
 52- Implement Entra ID authentication or SAS tokens for applications currently using storage account keys to reduce future risk.
 53- Configure Azure Policy to restrict the listKeys operation to specific roles or require additional approval workflows.
 54- Review and potentially restrict the assignment of high-privilege roles like Owner and Contributor, following the principle of least privilege.
 55- Enable diagnostic logging for all storage accounts to maintain detailed audit trails of access and operations.
 56- Consider implementing Privileged Identity Management (PIM) for just-in-time access to high-privilege roles that can list storage keys.
 57"""
 58references = [
 59    "https://www.microsoft.com/en-us/security/blog/2025/08/27/storm-0501s-evolving-techniques-lead-to-cloud-based-ransomware/",
 60    "https://docs.microsoft.com/en-us/azure/storage/common/storage-account-keys-manage"
 61]
 62risk_score = 47
 63rule_id = "8b4d6c3a-2e9f-4b7c-9a5d-6f8e3c1b4d2a"
 64severity = "medium"
 65tags = [
 66    "Domain: Cloud",
 67    "Domain: Identity",
 68    "Use Case: Threat Detection",
 69    "Data Source: Azure",
 70    "Data Source: Azure Activity Logs",
 71    "Tactic: Credential Access",
 72    "Resources: Investigation Guide",
 73]
 74timestamp_override = "event.ingested"
 75type = "new_terms"
 76
 77query = '''
 78event.dataset: "azure.activitylogs" and
 79azure.activitylogs.operation_name: "MICROSOFT.STORAGE/STORAGEACCOUNTS/LISTKEYS/ACTION" and
 80azure.activitylogs.identity.authorization.evidence.principal_type: "User" and
 81azure.activitylogs.identity.authorization.evidence.role: (
 82    "Owner" or
 83    "Contributor" or
 84    "Storage Account Contributor" or
 85    "User Access Administrator"
 86) and event.outcome: "success"
 87'''
 88
 89[rule.new_terms]
 90field = "new_terms_fields"
 91value = ["azure.activitylogs.identity.authorization.evidence.principal_id", "azure.resource.name"]
 92[[rule.new_terms.history_window_start]]
 93field = "history_window_start"
 94value = "now-7d"
 95
 96
 97[[rule.threat]]
 98framework = "MITRE ATT&CK"
 99[[rule.threat.technique]]
100id = "T1555"
101name = "Credentials from Password Stores"
102reference = "https://attack.mitre.org/techniques/T1555/"
103[[rule.threat.technique.subtechnique]]
104id = "T1555.006"
105name = "Cloud Secrets Management Stores"
106reference = "https://attack.mitre.org/techniques/T1555/006/"
107
108
109[rule.threat.tactic]
110id = "TA0006"
111name = "Credential Access"
112reference = "https://attack.mitre.org/tactics/TA0006/"
113
114[[rule.threat]]
115framework = "MITRE ATT&CK"
116[[rule.threat.technique]]
117id = "T1078"
118name = "Valid Accounts"
119reference = "https://attack.mitre.org/techniques/T1078/"
120[[rule.threat.technique.subtechnique]]
121id = "T1078.004"
122name = "Cloud Accounts"
123reference = "https://attack.mitre.org/techniques/T1078/004/"
124
125
126[rule.threat.tactic]
127id = "TA0001"
128name = "Initial Access"
129reference = "https://attack.mitre.org/tactics/TA0001/"```