nldcsc-elastic-rules 0.0.8__py3-none-any.whl

nldcsc_elastic_rules/rules/integrations/azure/execution_command_virtual_machine.toml

@@ -0,0 +1,96 @@
+[metadata]
+creation_date = "2020/08/17"
+integration = ["azure"]
+maturity = "production"
+updated_date = "2025/09/30"
+
+[rule]
+author = ["Elastic"]
+description = """
+Identifies command execution on a virtual machine (VM) in Azure. A Virtual Machine Contributor role lets you manage
+virtual machines, but not access them, nor access the virtual network or storage account they’re connected to. However,
+commands can be run via PowerShell on the VM, which execute as System. Other roles, such as certain Administrator roles
+may be able to execute commands on a VM as well.
+"""
+false_positives = [
+    """
+    Command execution on a virtual machine may be done by a system or network administrator. Verify whether the
+    username, hostname, and/or resource name should be making changes in your environment. Command execution from
+    unfamiliar users or hosts should be investigated. If known behavior is causing false positives, it can be exempted
+    from the rule.
+    """,
+]
+from = "now-9m"
+index = ["logs-azure.activitylogs-*", "filebeat-*"]
+language = "kuery"
+license = "Elastic License v2"
+name = "Azure Command Execution on Virtual Machine"
+note = """## Triage and analysis
+
+> **Disclaimer**:
+> This investigation guide was created using generative AI technology and has been reviewed to improve its accuracy and relevance. While every effort has been made to ensure its quality, we recommend validating the content and adapting it to suit your specific environment and operational needs.
+
+### Investigating Azure Command Execution on Virtual Machine
+
+Azure Virtual Machines (VMs) allow users to run applications and services in the cloud. While roles like Virtual Machine Contributor can manage VMs, they typically can't access them directly. However, commands can be executed remotely via PowerShell, running as System. Adversaries may exploit this to execute unauthorized commands. The detection rule monitors Azure activity logs for command execution events, flagging successful operations to identify potential misuse.
+
+### Possible investigation steps
+
+- Review the Azure activity logs to identify the specific user or service principal that initiated the command execution event, focusing on the operation_name "MICROSOFT.COMPUTE/VIRTUALMACHINES/RUNCOMMAND/ACTION".
+- Check the event.outcome field to confirm the success of the command execution and gather details about the command executed.
+- Investigate the role and permissions of the user or service principal involved to determine if they have legitimate reasons to execute commands on the VM.
+- Analyze the context of the command execution, including the time and frequency of the events, to identify any unusual patterns or anomalies.
+- Correlate the command execution event with other logs or alerts from the same time period to identify any related suspicious activities or potential lateral movement.
+- If unauthorized access is suspected, review the VM's security settings and access controls to identify and mitigate any vulnerabilities or misconfigurations.
+
+### False positive analysis
+
+- Routine maintenance tasks executed by IT administrators can trigger the rule. To manage this, create exceptions for known maintenance scripts or scheduled tasks that are regularly executed.
+- Automated deployment processes that use PowerShell scripts to configure or update VMs may be flagged. Identify these processes and exclude them from the rule to prevent unnecessary alerts.
+- Security tools or monitoring solutions that perform regular checks on VMs might execute commands that are benign. Whitelist these tools by identifying their specific command patterns and excluding them from detection.
+- Development and testing environments often involve frequent command executions for testing purposes. Consider excluding these environments from the rule or setting up a separate monitoring policy with adjusted thresholds.
+- Ensure that any exclusion or exception is documented and reviewed periodically to maintain security posture and adapt to any changes in the environment or processes.
+
+### Response and remediation
+
+- Immediately isolate the affected virtual machine from the network to prevent further unauthorized command execution and potential lateral movement.
+- Review the Azure activity logs to identify the source of the command execution and determine if it was authorized or part of a larger attack pattern.
+- Revoke any unnecessary permissions from users or roles that have the ability to execute commands on virtual machines, focusing on those with Virtual Machine Contributor roles.
+- Conduct a thorough investigation of the executed commands to assess any changes or impacts on the system, and restore the VM to a known good state if necessary.
+- Implement additional monitoring and alerting for similar command execution activities, ensuring that any future unauthorized attempts are detected promptly.
+- Escalate the incident to the security operations team for further analysis and to determine if additional systems or data may have been compromised.
+- Review and update access control policies and role assignments to ensure that only necessary permissions are granted, reducing the risk of similar incidents in the future.
+
+## Setup
+
+The Azure Fleet integration, Filebeat module, or similarly structured data is required to be compatible with this rule."""
+references = [
+    "https://adsecurity.org/?p=4277",
+    "https://posts.specterops.io/attacking-azure-azure-ad-and-introducing-powerzure-ca70b330511a",
+    "https://docs.microsoft.com/en-us/azure/role-based-access-control/built-in-roles#virtual-machine-contributor",
+]
+risk_score = 47
+rule_id = "60884af6-f553-4a6c-af13-300047455491"
+severity = "medium"
+tags = ["Domain: Cloud", "Data Source: Azure", "Use Case: Log Auditing", "Tactic: Execution", "Resources: Investigation Guide"]
+timestamp_override = "event.ingested"
+type = "query"
+
+query = '''
+event.dataset:azure.activitylogs and azure.activitylogs.operation_name:"MICROSOFT.COMPUTE/VIRTUALMACHINES/RUNCOMMAND/ACTION" and event.outcome:(Success or success)
+'''
+
+
+[[rule.threat]]
+framework = "MITRE ATT&CK"
+[[rule.threat.technique]]
+id = "T1651"
+name = "Cloud Administration Command"
+reference = "https://attack.mitre.org/techniques/T1651/"
+
+
+[rule.threat.tactic]
+id = "TA0002"
+name = "Execution"
+reference = "https://attack.mitre.org/tactics/TA0002/"
+

nldcsc_elastic_rules/rules/integrations/azure/exfiltration_azure_storage_blob_download_azcopy_sas_token.toml

@@ -0,0 +1,121 @@
+[metadata]
+creation_date = "2025/10/02"
+integration = ["azure"]
+maturity = "production"
+updated_date = "2025/10/02"
+
+[rule]
+author = ["Elastic"]
+description = """
+Identifies successful GetBlob operations on Azure Storage Accounts using AzCopy user agent with SAS token
+authentication. AzCopy is a command-line utility for copying data to and from Azure Storage. While legitimate for data
+migration, adversaries may abuse AzCopy with compromised SAS tokens to exfiltrate data from Azure Storage Accounts. This
+rule detects the first occurrence of GetBlob operations from a specific storage account using this pattern.
+"""
+false_positives = [
+    "Legitimate data migration or backup operations using AzCopy with SAS tokens may trigger this rule.",
+    "Automated scripts or processes that use AzCopy for routine data transfers from Azure Storage Accounts.",
+    "DevOps or IT teams performing authorized data transfers or downloads from Azure Storage using AzCopy.",
+]
+from = "now-9m"
+index = ["logs-azure.platformlogs-*"]
+language = "kuery"
+license = "Elastic License v2"
+name = "Azure Storage Blob Retrieval via AzCopy"
+note = """## Triage and analysis
+
+### Investigating Azure Storage Blob Retrieval via AzCopy
+
+Azure Storage Accounts provide cloud storage services for blobs, files, queues, and tables. Shared Access Signatures (SAS) tokens provide delegated access to resources in a storage account with specific permissions and time constraints. AzCopy is a Microsoft command-line utility designed for efficient data transfers to and from Azure Storage. While AzCopy is a legitimate tool, adversaries may abuse it with compromised SAS tokens to exfiltrate data from Azure Storage Accounts.
+
+### Possible investigation steps
+- Review the `azure.platformlogs.properties.accountName` field to identify which storage account is being accessed and assess the sensitivity of data stored in that account.
+- Examine the `azure.platformlogs.properties.objectKey` field to identify the specific blob(s) being retrieved. Determine if the accessed files contain sensitive or confidential data.
+- Check the `source.address` field to identify the source IP address of the request. Investigate if this IP is unusual, unexpected, or originates from an unexpected network or geographic location.
+- Review the `azure.platformlogs.uri` field to examine the SAS token parameters, including:
+  - `se` (expiry time): Check when the SAS token expires
+  - `sp` (permissions): Verify what permissions were granted (e.g., "rl" for read and list)
+  - `sv` (API version): Note the storage service version being used
+- Examine the `azure.platformlogs.identity.tokenHash` field to identify the specific SAS token signature being used. Correlate this with SAS token generation logs to determine when and how the token was created.
+- Check the `azure.platformlogs.properties.responseBodySize` field to assess the volume of data being downloaded. Multiple GetBlob operations with large response sizes may indicate bulk data exfiltration.
+- Search for related GetBlob operations from the same `source.address` or with the same `azure.platformlogs.identity.tokenHash` to identify patterns of systematic data retrieval.
+- Review Azure Activity Logs for recent SAS token generation events or storage account key access operations that may indicate how the adversary obtained the credentials.
+- Correlate this activity with ListBlobs or ListContainers operations from the same source, as adversaries often enumerate storage contents before exfiltration.
+- Investigate the `azure.resource.group` field to understand which resource group the storage account belongs to and check for any recent security events or configuration changes in that resource group.
+
+### False positive analysis
+- Routine data migration or backup operations using AzCopy with SAS tokens are common in enterprise environments. If this is expected behavior for the storage account, consider adding exceptions for specific accounts or IP ranges.
+- DevOps pipelines or automated workflows may use AzCopy with SAS tokens for legitimate data transfers. Review the automation configuration and add exceptions if appropriate.
+- Third-party services or partners may have authorized access to storage accounts using AzCopy and SAS tokens. Verify these relationships and create exceptions for known authorized sources.
+
+### Response and remediation
+- If unauthorized access is confirmed, immediately revoke the compromised SAS token to prevent further data exfiltration.
+- Review and rotate any additional SAS tokens that may have been compromised through the same attack vector.
+- Assess the scope of data accessed or exfiltrated during the unauthorized GetBlob operations and determine if sensitive data was compromised.
+- Implement additional monitoring and alerting for the affected storage account to detect any further suspicious activity.
+- Review and strengthen SAS token generation policies, including implementing shorter expiration times and more restrictive permissions.
+- Consider implementing Azure Storage firewall rules or private endpoints to restrict access to storage accounts from trusted networks only.
+- Investigate how the SAS token was compromised and remediate the initial access vector to prevent future incidents.
+- Document the incident and update security procedures to prevent similar compromises in the future.
+"""
+references = [
+    "https://www.microsoft.com/en-us/security/blog/2025/08/27/storm-0501s-evolving-techniques-lead-to-cloud-based-ransomware/",
+    "https://learn.microsoft.com/en-us/azure/storage/common/storage-use-azcopy-v10",
+    "https://learn.microsoft.com/en-us/azure/storage/common/storage-sas-overview",
+]
+risk_score = 47
+rule_id = "a8b3c4d5-e6f7-8901-a2b3-c4d5e6f78901"
+setup = """#### Required Azure Storage Diagnostic Logs
+
+To ensure this rule functions correctly, the following diagnostic logs must be enabled for Azure Storage Accounts:
+- StorageRead: This log captures all read operations performed on blobs in the storage account, including GetBlob operations. These logs should be streamed to the Event Hub used for the Azure integration configuration.
+"""
+severity = "medium"
+tags = [
+    "Domain: Cloud",
+    "Domain: Storage",
+    "Data Source: Azure",
+    "Data Source: Azure Platform Logs",
+    "Data Source: Azure Storage",
+    "Use Case: Threat Detection",
+    "Tactic: Exfiltration",
+    "Resources: Investigation Guide",
+]
+timestamp_override = "event.ingested"
+type = "new_terms"
+
+query = '''
+event.dataset: azure.platformlogs and
+    event.action: GetBlob and
+    azure.platformlogs.identity.type: SAS and
+    azure.platformlogs.properties.userAgentHeader: AzCopy* and
+    azure.platformlogs.statusCode: 200
+'''
+
+
+[[rule.threat]]
+framework = "MITRE ATT&CK"
+[[rule.threat.technique]]
+id = "T1567"
+name = "Exfiltration Over Web Service"
+reference = "https://attack.mitre.org/techniques/T1567/"
+[[rule.threat.technique.subtechnique]]
+id = "T1567.002"
+name = "Exfiltration to Cloud Storage"
+reference = "https://attack.mitre.org/techniques/T1567/002/"
+
+
+
+[rule.threat.tactic]
+id = "TA0010"
+name = "Exfiltration"
+reference = "https://attack.mitre.org/tactics/TA0010/"
+
+[rule.new_terms]
+field = "new_terms_fields"
+value = ["azure.platformlogs.properties.accountName"]
+[[rule.new_terms.history_window_start]]
+field = "history_window_start"
+value = "now-7d"
+
+

nldcsc_elastic_rules/rules/integrations/azure/impact_azure_compute_restore_point_collection_deleted.toml

@@ -0,0 +1,111 @@
+[metadata]
+creation_date = "2025/10/13"
+integration = ["azure"]
+maturity = "production"
+updated_date = "2025/10/13"
+
+[rule]
+author = ["Elastic"]
+description = """
+Identifies the deletion of Azure Restore Point Collections by a user who has not previously performed this activity.
+Restore Point Collections contain recovery points for virtual machines, enabling point-in-time recovery capabilities.
+Adversaries may delete these collections to prevent recovery during ransomware attacks or to cover their tracks during
+malicious operations.
+"""
+false_positives = [
+    """
+    Restore Point Collection deletions may be performed by system administrators during routine cleanup or
+    decommissioning activities. Verify whether the user and resource should be performing these operations. Deletions
+    from unfamiliar users or targeting critical resources should be investigated. If known behavior is causing false
+    positives, it can be exempted from the rule.
+    """,
+]
+from = "now-9m"
+index = ["logs-azure.activitylogs-*", "filebeat-*"]
+language = "kuery"
+license = "Elastic License v2"
+name = "Azure Compute Restore Point Collection Deleted by Unusual User"
+note = """## Triage and analysis
+
+### Investigating Azure Compute Restore Point Collection Deleted by Unusual User
+
+Azure Compute Restore Point Collections are critical components for disaster recovery, containing snapshots that enable point-in-time
+recovery of virtual machines. Deletion of these collections can severely impact an organization's ability to recover from
+incidents, making them attractive targets for adversaries conducting ransomware attacks or attempting to cover their tracks.
+
+This rule detects when a user who has not previously deleted Restore Point Collections performs this operation, which may
+indicate unauthorized activity or a compromised account.
+
+### Possible investigation steps
+
+- Review the `azure.activitylogs.identity.claims_initiated_by_user.name` field to identify the specific user who performed the deletion operation.
+- Investigate the `azure.resource.id` or `azure.resource.name` fields to identify which Restore Point Collection was deleted and assess its criticality to business operations.
+- Review the timeline of the deletion event and correlate it with other security events or user activities to identify any suspicious patterns or related activities.
+- Verify whether the user account has legitimate access to perform this operation and whether this deletion was authorized through change management processes.
+- Check for any other unusual activities by the same user account around the time of the deletion, such as privilege escalation attempts or access to other sensitive resources.
+- Investigate whether there are any active alerts or indicators of compromise related to ransomware activity in the environment.
+
+### False positive analysis
+
+- Routine administrative activities by infrastructure teams may trigger this alert when team members rotate or new administrators are onboarded. Create exceptions for known administrative accounts after verification.
+- Automated cleanup scripts or Azure policies that periodically remove old restore points may cause alerts. Identify and exclude service accounts used for these automated operations.
+- Planned decommissioning activities or migration projects may involve legitimate deletion of restore point collections. Document these activities and create temporary exceptions during known maintenance windows.
+- Testing and development environments may see frequent creation and deletion of resources. Consider excluding these environments from monitoring or adjusting the rule to focus on production resources only.
+
+### Response and remediation
+
+- Immediately verify the legitimacy of the deletion operation with the user or their manager. If the activity is unauthorized, proceed with incident response procedures.
+- If unauthorized deletion is confirmed, immediately isolate the affected user account to prevent further malicious activity. Reset credentials and review account permissions.
+- Check if the deleted Restore Point Collection can be recovered through Azure backup services or other recovery mechanisms.
+- Review and audit all recent activities performed by the affected user account to identify other potentially malicious actions.
+- Assess the impact on disaster recovery capabilities and inform relevant stakeholders about potential recovery limitations.
+- Review access controls and permissions for Restore Point Collection management, implementing principle of least privilege where necessary.
+- If ransomware activity is suspected, escalate to the security incident response team and implement broader containment measures, including checking for other indicators of ransomware such as deletion of Recovery Services vaults or backup fabric containers.
+- Document the incident and update detection rules or procedures based on lessons learned.
+"""
+references = [
+    "https://www.microsoft.com/en-us/security/blog/2023/07/25/storm-0501-ransomware-attacks-expanding-to-hybrid-cloud-environments/",
+]
+risk_score = 47
+rule_id = "c1a3e2f0-8a1b-11ef-9b4a-f661ea17fbce"
+severity = "medium"
+tags = [
+    "Domain: Cloud",
+    "Domain: Storage",
+    "Data Source: Azure",
+    "Data Source: Azure Activity Logs",
+    "Use Case: Threat Detection",
+    "Tactic: Impact",
+    "Resources: Investigation Guide",
+]
+timestamp_override = "event.ingested"
+type = "new_terms"
+
+query = '''
+event.dataset: azure.activitylogs and
+    event.action: "MICROSOFT.COMPUTE/RESTOREPOINTCOLLECTIONS/DELETE" and
+    event.outcome: (Success or success)
+'''
+
+
+[[rule.threat]]
+framework = "MITRE ATT&CK"
+[[rule.threat.technique]]
+id = "T1490"
+name = "Inhibit System Recovery"
+reference = "https://attack.mitre.org/techniques/T1490/"
+
+
+[rule.threat.tactic]
+id = "TA0040"
+name = "Impact"
+reference = "https://attack.mitre.org/tactics/TA0040/"
+
+[rule.new_terms]
+field = "new_terms_fields"
+value = ["azure.activitylogs.identity.claims_initiated_by_user.name", "azure.resource.group"]
+[[rule.new_terms.history_window_start]]
+field = "history_window_start"
+value = "now-7d"
+
+

nldcsc_elastic_rules/rules/integrations/azure/impact_azure_compute_restore_point_collections_deleted.toml

@@ -0,0 +1,132 @@
+[metadata]
+creation_date = "2025/10/13"
+integration = ["azure"]
+maturity = "production"
+updated_date = "2025/10/13"
+
+[rule]
+author = ["Elastic"]
+description = """
+Identifies multiple Azure Restore Point Collections being deleted by a single user within a short time period. Restore
+Point Collections contain recovery points for virtual machines, enabling point-in-time recovery capabilities. Mass
+deletion of these collections is a common tactic used by adversaries during ransomware attacks to prevent victim
+recovery or to maximize impact during destructive operations. Multiple deletions in rapid succession may indicate
+malicious intent.
+"""
+false_positives = [
+    """
+    Planned decommissioning activities or large-scale infrastructure changes may result in legitimate bulk deletion of
+    Restore Point Collections. Verify with the user and change management processes whether these deletions are
+    authorized. Large-scale migration or cleanup projects should be coordinated and documented to avoid false positives.
+    """,
+]
+from = "now-9m"
+index = ["logs-azure.activitylogs-*", "filebeat-*"]
+language = "kuery"
+license = "Elastic License v2"
+name = "Azure Compute Restore Point Collections Deleted"
+note = """## Triage and analysis
+
+### Investigating Azure Compute Restore Point Collections Deleted
+
+Azure Compute Restore Point Collections are essential for disaster recovery, containing snapshots that enable point-in-time recovery
+of virtual machines. The ability to quickly restore VMs from these recovery points is critical for business continuity and
+incident response.
+
+Adversaries conducting ransomware attacks or destructive operations often target backup and recovery infrastructure to
+prevent victims from recovering their systems without paying a ransom. Mass deletion of Restore Point Collections is a
+key indicator of such activity and represents a significant threat to an organization's resilience.
+
+This rule detects when a single user deletes multiple Restore Point Collections within a short time window, which is
+unusual in normal operations and highly suspicious when observed.
+
+### Possible investigation steps
+
+- Identify the user account responsible for the deletions by examining the `azure.activitylogs.identity.claims_initiated_by_user.name` or `user.name` field in the alerts.
+- Review all deletion events from this user in the specified time window to determine the scope and scale of the activity.
+- Check the `azure.resource.id` and `azure.resource.name` fields to identify which Restore Point Collections were deleted and assess their criticality to business operations.
+- Verify whether the user account has legitimate administrative access and whether these deletions were authorized through change management or documented maintenance activities.
+- Investigate the timeline of events leading up to the deletions, looking for other suspicious activities such as:
+    - Privilege escalation attempts
+    - Deletion of other backup resources (Recovery Services vaults, backup policies)
+    - Unusual authentication patterns or geographic anomalies
+    - Creation of persistence mechanisms or backdoor accounts
+- Review Azure Activity Logs for any failed deletion attempts or access denied events that might indicate reconnaissance activities preceding the successful deletions.
+- Check for related data destruction activities, such as deletion of virtual machines, disks, or storage accounts.
+- Correlate with sign-in logs to identify any unusual login patterns or potential account compromise indicators.
+
+### False positive analysis
+
+- Large-scale decommissioning projects may involve legitimate deletion of multiple Restore Point Collections. Verify with change management records and create temporary exceptions during documented maintenance windows.
+- Infrastructure migrations from Azure to another platform or between Azure regions may involve cleanup of old restore points. Confirm these activities are planned and documented before excluding them from monitoring.
+- Automated cleanup scripts designed to manage storage costs by removing old restore points might trigger this alert. Identify the service accounts used for these operations and adjust the threshold or create exceptions as appropriate.
+- Testing and development environments that are frequently rebuilt may see regular bulk deletion of resources. Consider excluding non-production environments or adjusting the threshold for these subscriptions.
+- Review the threshold value (currently set to 3) and adjust based on your environment's baseline if legitimate administrative activities are frequently triggering false positives.
+
+### Response and remediation
+
+- Immediately isolate the affected user account to prevent further malicious activity. Reset credentials and revoke active sessions.
+- Verify the legitimacy of the deletions with the account owner or their manager. If unauthorized, treat this as a confirmed security incident and activate incident response procedures.
+- Check if any of the deleted Restore Point Collections can be recovered through Azure backup services, soft-delete features, or other recovery mechanisms. Time is critical as retention policies may limit recovery windows.
+- Conduct a comprehensive review of all recent activities by the affected user account across the Azure environment to identify other potentially malicious actions or compromised resources.
+- Assess the current disaster recovery posture and identify which VMs are now missing recovery points. Prioritize creation of new restore points for critical systems if they are unaffected.
+- Review and strengthen access controls for Restore Point Collection management, implementing stricter RBAC policies and requiring multi-factor authentication for privileged operations.
+- If ransomware activity is suspected or confirmed:
+    - Activate the organization's ransomware response plan
+    - Isolate affected systems to prevent spread
+    - Search for ransomware indicators across the environment (encrypted files, ransom notes, suspicious processes)
+    - Check for deletion of other recovery resources (Recovery Services vaults, backups, snapshots)
+    - Do not pay ransom demands; engage with law enforcement and cybersecurity incident response teams
+- Implement additional monitoring and alerting for related activities such as:
+    - Deletion of Recovery Services resources
+    - Modifications to backup policies
+    - Unusual access to disaster recovery infrastructure
+- Document the incident thoroughly and conduct a post-incident review to identify gaps in security controls and opportunities for improvement.
+- Consider implementing Azure Resource Locks on critical recovery resources to prevent accidental or malicious deletion.
+"""
+references = [
+    "https://www.microsoft.com/en-us/security/blog/2023/07/25/storm-0501-ransomware-attacks-expanding-to-hybrid-cloud-environments/",
+]
+risk_score = 73
+rule_id = "d8f4e3b0-8a1b-11ef-9b4a-f661ea17fbce"
+severity = "high"
+tags = [
+    "Domain: Cloud",
+    "Domain: Storage",
+    "Data Source: Azure",
+    "Data Source: Azure Activity Logs",
+    "Use Case: Threat Detection",
+    "Tactic: Impact",
+    "Resources: Investigation Guide",
+]
+timestamp_override = "event.ingested"
+type = "threshold"
+
+query = '''
+event.dataset: azure.activitylogs and
+    event.action: "MICROSOFT.COMPUTE/RESTOREPOINTCOLLECTIONS/DELETE" and
+    event.outcome: (Success or success)
+'''
+
+
+[[rule.threat]]
+framework = "MITRE ATT&CK"
+[[rule.threat.technique]]
+id = "T1490"
+name = "Inhibit System Recovery"
+reference = "https://attack.mitre.org/techniques/T1490/"
+
+
+[rule.threat.tactic]
+id = "TA0040"
+name = "Impact"
+reference = "https://attack.mitre.org/tactics/TA0040/"
+
+[rule.threshold]
+field = ["azure.activitylogs.identity.claims_initiated_by_user.name"]
+value = 1
+[[rule.threshold.cardinality]]
+field = "azure.activitylogs.resource.id"
+value = 3
+
+

nldcsc_elastic_rules/rules/integrations/azure/impact_azure_compute_vm_snapshot_deletion.toml

@@ -0,0 +1,132 @@
+[metadata]
+creation_date = "2025/10/10"
+integration = ["azure"]
+maturity = "production"
+updated_date = "2025/10/10"
+
+[rule]
+author = ["Elastic"]
+description = """
+Identifies when an Azure disk snapshot is deleted by an unusual user in a specific resource group. Snapshots are
+critical for backup, disaster recovery, and forensic analysis. Adversaries may delete snapshots to prevent data
+recovery, eliminate forensic evidence, or disrupt backup strategies before executing ransomware or other destructive
+attacks. Monitoring snapshot deletions is essential for detecting potential attacks targeting backup and recovery
+capabilities.
+"""
+false_positives = [
+    """
+    Storage administrators may legitimately delete snapshots during routine maintenance, storage optimization, or
+    cleanup of old backup data. Verify that the deletion was expected and follows organizational data retention
+    policies. Consider exceptions for approved maintenance windows or automated retention management tools.
+    """,
+]
+from = "now-9m"
+index = ["logs-azure.activitylogs-*"]
+language = "kuery"
+license = "Elastic License v2"
+name = "Azure Compute Snapshot Deletion by Unusual User and Resource Group"
+note = """## Triage and analysis
+
+### Investigating Azure Compute Snapshot Deletion by Unusual User and Resource Group
+
+Azure disk snapshots provide point-in-time copies of managed disks, serving as critical components for backup strategies, disaster recovery plans, and forensic investigations. Snapshots enable organizations to restore data and reconstruct system states after security incidents. Adversaries aware of backup strategies may delete snapshots to prevent recovery, eliminate forensic evidence, or maximize impact before executing ransomware attacks. This detection monitors for snapshot deletion operations to identify potential attempts to compromise backup and recovery capabilities. This is a New Terms rule that looks for this behavior by a user and resource group that has not been seen in the last 7 days.
+
+### Possible investigation steps
+
+- Review the Azure activity logs to identify the user or service principal that initiated the snapshot deletion by examining the principal ID, UPN and user agent fields.
+- Check the specific snapshot name in `azure.resource.name` to understand which backup was deleted and assess the potential impact on recovery capabilities.
+- Investigate the timing of the event to correlate with any other suspicious activities, such as unusual login patterns, privilege escalation attempts, or other resource deletions.
+- Examine the user's recent activity history to identify any other snapshots, disks, or Azure resources that were deleted or modified by the same principal.
+- Verify if the snapshot deletion aligns with approved change requests, maintenance windows, or data retention policies in your organization.
+- Check if other backup-related resources (backup vaults, recovery services) were accessed or modified around the same time.
+- Review any related alerts or activities such as data encryption, VM modifications, or access policy changes that occurred before the deletion.
+- Investigate if the account was recently compromised by checking for suspicious authentication events or privilege escalations.
+
+### False positive analysis
+
+- Legitimate cleanup of expired snapshots according to data retention policies may trigger this alert. Document approved retention management processes and consider creating exceptions for automated retention tools or scheduled cleanup activities.
+- DevOps automation tools might delete temporary snapshots created during deployment or testing processes. Identify service principals used by CI/CD pipelines and consider time-based exceptions during deployment windows.
+- Storage optimization initiatives may involve deleting old or redundant snapshots to reduce costs. Coordinate with infrastructure teams to understand planned optimization activities and create exceptions during documented maintenance windows.
+- Disaster recovery testing may involve creating and deleting test snapshots. Work with business continuity teams to identify these patterns and create exceptions during scheduled DR testing periods.
+
+### Response and remediation
+
+- Immediately investigate whether the deletion was authorized by verifying with the account owner, backup administrators, or relevant stakeholders.
+- If the deletion was unauthorized, disable the compromised user account or service principal immediately to prevent further damage.
+- Check if the snapshot can be recovered through Azure backup services or soft-delete capabilities if enabled.
+- Create new snapshots of critical disks immediately if the deleted snapshot was part of your backup strategy.
+- Review and audit all Azure RBAC permissions to identify how the attacker gained snapshot deletion capabilities.
+- Conduct a full security assessment to identify the initial access vector and any other compromised accounts or resources.
+- Implement Azure Resource Locks on critical snapshots to prevent accidental or malicious deletion.
+- Configure Azure Policy to restrict snapshot deletion permissions to only authorized backup administrators.
+- Enable Azure Activity Log alerts to notify security teams immediately when snapshots are deleted.
+- Review backup and disaster recovery procedures to ensure redundant backup mechanisms exist beyond Azure snapshots.
+- Document the incident and update security policies and procedures to prevent similar incidents in the future.
+"""
+references = [
+    "https://www.microsoft.com/en-us/security/blog/2025/08/27/storm-0501s-evolving-techniques-lead-to-cloud-based-ransomware/",
+]
+risk_score = 21
+rule_id = "c3d4e5f6-7a8b-9c0d-1e2f-3a4b5c6d7e8f"
+severity = "low"
+tags = [
+    "Domain: Cloud",
+    "Domain: Storage",
+    "Data Source: Azure",
+    "Data Source: Azure Activity Logs",
+    "Use Case: Threat Detection",
+    "Tactic: Impact",
+    "Resources: Investigation Guide",
+]
+timestamp_override = "event.ingested"
+type = "new_terms"
+
+query = '''
+event.dataset: azure.activitylogs and
+    azure.activitylogs.operation_name: "MICROSOFT.COMPUTE/SNAPSHOTS/DELETE" and
+    azure.activitylogs.properties.status_code: "Accepted" and
+    azure.activitylogs.identity.claims_initiated_by_user.name: *
+'''
+
+[rule.investigation_fields]
+field_names = [
+    "@timestamp",
+    "azure.activitylogs.identity.claims_initiated_by_user.name",
+    "azure.activitylogs.identity.authorization.evidence.principal_id",
+    "azure.activitylogs.identity.claims.appid",
+    "azure.activitylogs.identity.claims.sid",
+    "azure.resource.name",
+    "azure.resource.group",
+    "azure.activitylogs.operation_name",
+    "azure.subscription_id",
+    "azure.activitylogs.tenant_id",
+    "source.ip",
+]
+
+
+[[rule.threat]]
+framework = "MITRE ATT&CK"
+[[rule.threat.technique]]
+id = "T1485"
+name = "Data Destruction"
+reference = "https://attack.mitre.org/techniques/T1485/"
+
+[[rule.threat.technique]]
+id = "T1490"
+name = "Inhibit System Recovery"
+reference = "https://attack.mitre.org/techniques/T1490/"
+
+
+[rule.threat.tactic]
+id = "TA0040"
+name = "Impact"
+reference = "https://attack.mitre.org/tactics/TA0040/"
+
+[rule.new_terms]
+field = "new_terms_fields"
+value = ["azure.activitylogs.identity.claims_initiated_by_user.name", "azure.resource.group"]
+[[rule.new_terms.history_window_start]]
+field = "history_window_start"
+value = "now-7d"
+
+