[New Rule] Azure Storage Account Keys Accessed by Privileged User (#5141)

<!--
Thank you for your interest in and contributing to Detection Rules!
There are a few simple things to check before submitting your pull request
that can help with the review process. You should delete these items
from your submission, but they are here to help bring them to your attention.
-->
# Pull Request

*Issue link(s)*:
* #5140

<!--
  Add Related Issues / PRs for context. Eg:
    Related to elastic/repo#999
    Resolves #123
  If there is no issue link, take extra care to write a clear summary and label the PR just as you would label an issue to give additional context to reviewers.
-->

## Summary - What I changed
Adds missing detection coverage for retrieving Azure Storage Account keys by a user with highly-privileged roles. Please see the related issue for more details.

<!--
  Summarize your PR. Animated gifs are 💯. Code snippets are ⚡️. Examples & screenshots are 🔥
-->

## How To Test
Query can be used in TRADE stack for telemetry visbility.

<!--
  Some examples of what you could include here are:
  * Links to GitHub action results for CI test improvements
  * Sample data before/after screenshots (or short videos showing how something works)
  * Copy/pasted commands and output from the testing you did in your local terminal window
  * If tests run in GitHub, you can 🪁or 🔱, respectively, to indicate tests will run in CI
  * Query used in your stack to verify the change
-->

## Checklist

<!-- Delete any items that are not applicable to this PR. -->

- [ ] Added a label for the type of pr: `bug`, `enhancement`, `schema`, `maintenance`, `Rule: New`, `Rule: Deprecation`, `Rule: Tuning`, `Hunt: New`, or `Hunt: Tuning` so guidelines can be generated
- [ ] Added the `meta:rapid-merge` label if planning to merge within 24 hours
- [ ] Secret and sensitive material has been managed correctly
- [ ] Automated testing was updated or added to match the most common scenarios
- [ ] Documentation and comments were added for features that require explanation

## Contributor checklist

- Have you signed the [contributor license agreement](https://www.elastic.co/contributor-agreement)?
- Have you followed the [contributor guidelines](https://github.com/elastic/detection-rules/blob/main/CONTRIBUTING.md)?

(cherry picked from commit 0c739da)

Author: terrancedejesus

rules/integrations/azure/credential_access_azure_storage_account_keys_accessed.toml

@@ -0,0 +1,129 @@
+[metadata]
+creation_date = "2025/09/23"
+integration = ["azure"]
+maturity = "production"
+updated_date = "2025/09/23"
+
+[rule]
+author = ["Elastic"]
+description = """
+Identifies unusual high-privileged access to Azure Storage Account keys by users with Owner, Contributor, or Storage
+Account Contributor roles. This technique was observed in STORM-0501 ransomware campaigns where compromised identities
+with high-privilege Azure RBAC roles retrieved access keys to perform unauthorized operations on Storage Accounts.
+Microsoft recommends using Shared Access Signature (SAS) models instead of direct key access for improved security.
+This rule detects when a user principal with high-privilege roles accesses storage keys for the first time in 7 days.
+"""
+from = "now-9m"
+index = ["logs-azure.activitylogs-*"]
+language = "kuery"
+license = "Elastic License v2"
+name = "Azure Storage Account Keys Accessed by Privileged User"
+note = """## Triage and Analysis
+
+### Investigating Azure Storage Account Keys Accessed by Privileged User
+
+Azure 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.
+
+### Possible investigation steps
+
+- Review the `azure.activitylogs.identity.authorization.evidence.principal_id` to identify the specific user who accessed the storage account keys.
+- Examine the `azure.resource.name` field to determine which storage account's keys were accessed and assess the sensitivity of data stored there.
+- 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.
+- Investigate the timing and frequency of the key access event - multiple key retrievals in a short timeframe may indicate automated exfiltration attempts.
+- Review the source IP address and geographic location of the access request to identify any anomalous access patterns or locations.
+- Correlate this event with other activities by the same principal ID, looking for patterns such as permission escalations, unusual data access, or configuration changes.
+- Check Azure AD sign-in logs for the user around the same timeframe to identify any suspicious authentication events or MFA bypasses.
+- Examine subsequent storage account activities to determine if the retrieved keys were used for data access, modification, or exfiltration.
+
+### False positive analysis
+
+- 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.
+- Emergency troubleshooting scenarios may require administrators to retrieve storage keys. Establish a process for documenting these emergency accesses and review them regularly.
+- 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.
+- 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.
+- New storage account provisioning by administrators will often include initial key retrieval. Consider the age of the storage account when evaluating the risk level.
+
+### Response and remediation
+
+- Immediately rotate the storage account keys that were accessed using Azure Portal or Azure CLI.
+- Review all recent activities on the affected storage account to identify any unauthorized data access, modification, or exfiltration attempts.
+- If unauthorized access is confirmed, disable the compromised user account and initiate password reset procedures.
+- Audit all storage accounts accessible by the compromised identity and rotate keys for any accounts that may have been accessed.
+- Implement Entra ID authentication or SAS tokens for applications currently using storage account keys to reduce future risk.
+- Configure Azure Policy to restrict the listKeys operation to specific roles or require additional approval workflows.
+- Review and potentially restrict the assignment of high-privilege roles like Owner and Contributor, following the principle of least privilege.
+- Enable diagnostic logging for all storage accounts to maintain detailed audit trails of access and operations.
+- Consider implementing Privileged Identity Management (PIM) for just-in-time access to high-privilege roles that can list storage keys.
+"""
+references = [
+    "https://www.microsoft.com/en-us/security/blog/2025/08/27/storm-0501s-evolving-techniques-lead-to-cloud-based-ransomware/",
+    "https://docs.microsoft.com/en-us/azure/storage/common/storage-account-keys-manage"
+]
+risk_score = 47
+rule_id = "8b4d6c3a-2e9f-4b7c-9a5d-6f8e3c1b4d2a"
+severity = "medium"
+tags = [
+    "Domain: Cloud",
+    "Domain: Identity",
+    "Use Case: Threat Detection",
+    "Data Source: Azure",
+    "Data Source: Azure Activity Logs",
+    "Tactic: Credential Access",
+    "Resources: Investigation Guide",
+]
+timestamp_override = "event.ingested"
+type = "new_terms"
+
+query = '''
+event.dataset: "azure.activitylogs" and
+azure.activitylogs.operation_name: "MICROSOFT.STORAGE/STORAGEACCOUNTS/LISTKEYS/ACTION" and
+azure.activitylogs.identity.authorization.evidence.principal_type: "User" and
+azure.activitylogs.identity.authorization.evidence.role: (
+    "Owner" or
+    "Contributor" or
+    "Storage Account Contributor" or
+    "User Access Administrator"
+) and event.outcome: "success"
+'''
+
+[rule.new_terms]
+field = "new_terms_fields"
+value = ["azure.activitylogs.identity.authorization.evidence.principal_id", "azure.resource.name"]
+[[rule.new_terms.history_window_start]]
+field = "history_window_start"
+value = "now-7d"
+
+
+[[rule.threat]]
+framework = "MITRE ATT&CK"
+[[rule.threat.technique]]
+id = "T1555"
+name = "Credentials from Password Stores"
+reference = "https://attack.mitre.org/techniques/T1555/"
+[[rule.threat.technique.subtechnique]]
+id = "T1555.006"
+name = "Cloud Secrets Management Stores"
+reference = "https://attack.mitre.org/techniques/T1555/006/"
+
+
+[rule.threat.tactic]
+id = "TA0006"
+name = "Credential Access"
+reference = "https://attack.mitre.org/tactics/TA0006/"
+
+[[rule.threat]]
+framework = "MITRE ATT&CK"
+[[rule.threat.technique]]
+id = "T1078"
+name = "Valid Accounts"
+reference = "https://attack.mitre.org/techniques/T1078/"
+[[rule.threat.technique.subtechnique]]
+id = "T1078.004"
+name = "Cloud Accounts"
+reference = "https://attack.mitre.org/techniques/T1078/004/"
+
+
+[rule.threat.tactic]
+id = "TA0001"
+name = "Initial Access"
+reference = "https://attack.mitre.org/tactics/TA0001/"