diff --git a/rules/integrations/azure/collection_entra_auth_broker_sharepoint_access_for_user_principal.toml b/rules/integrations/azure/collection_entra_id_auth_broker_sharepoint_access_for_user_principal.toml similarity index 96% rename from rules/integrations/azure/collection_entra_auth_broker_sharepoint_access_for_user_principal.toml rename to rules/integrations/azure/collection_entra_id_auth_broker_sharepoint_access_for_user_principal.toml index 30b7a44a46f..f39053e8c03 100644 --- a/rules/integrations/azure/collection_entra_auth_broker_sharepoint_access_for_user_principal.toml +++ b/rules/integrations/azure/collection_entra_id_auth_broker_sharepoint_access_for_user_principal.toml @@ -2,7 +2,7 @@ creation_date = "2025/05/01" integration = ["azure"] maturity = "production" -updated_date = "2025/05/07" +updated_date = "2025/10/01" [rule] author = ["Elastic"] @@ -30,10 +30,10 @@ from = "now-9m" index = ["logs-azure.signinlogs-*"] language = "kuery" license = "Elastic License v2" -name = "Microsoft Entra ID SharePoint Access for User Principal via Auth Broker" +name = "Entra ID SharePoint Accessed by Unusual User and Microsoft Authentication Broker Client" note = """## Triage and analysis -### Investigating Microsoft Entra ID SharePoint Access for User Principal via Auth Broker +### Investigating Entra ID SharePoint Accessed by Unusual User and Microsoft Authentication Broker Client This rule identifies non-interactive sign-ins to SharePoint Online via the Microsoft Authentication Broker application using a refresh token or Primary Refresh Token (PRT). This type of activity may indicate token replay attacks, OAuth abuse, or automated access from previously consented apps or stolen sessions. diff --git a/rules/integrations/azure/collection_graph_email_access_by_unusual_public_client_via_graph.toml b/rules/integrations/azure/collection_graph_email_access_by_unusual_public_client_via_graph.toml index 65e8a76e9ff..1468fbe9427 100644 --- a/rules/integrations/azure/collection_graph_email_access_by_unusual_public_client_via_graph.toml +++ b/rules/integrations/azure/collection_graph_email_access_by_unusual_public_client_via_graph.toml @@ -2,7 +2,7 @@ creation_date = "2025/05/06" integration = ["azure"] maturity = "production" -updated_date = "2025/09/08" +updated_date = "2025/10/01" [rule] author = ["Elastic"] @@ -18,10 +18,10 @@ from = "now-9m" index = ["logs-azure.graphactivitylogs-*"] language = "kuery" license = "Elastic License v2" -name = "Suspicious Email Access by First-Party Application via Microsoft Graph" +name = "Microsoft Graph Request Email Access by Unusual User and Client" note = """## Triage and analysis -### Investigating Suspicious Email Access by First-Party Application via Microsoft Graph +### Investigating Microsoft Graph Request Email Access by Unusual User and Client This rule detects instances where a previously unseen or rare Microsoft Graph application client ID accesses email-related APIs, such as `/me/messages`, `/sendMail`, or `/mailFolders/inbox/messages`. These accesses are performed via delegated user credentials using common OAuth scopes like `Mail.Read`, `Mail.ReadWrite`, `Mail.Send`, or `email`. This activity may indicate unauthorized use of a newly consented or compromised application to read or exfiltrate mail content. This is a New Terms rule that only signals if the application ID (`azure.graphactivitylogs.properties.app_id`) and user principal object ID (`azure.graphactivitylogs.properties.user_principal_object_id`) have not been seen doing this activity in the last 14 days. diff --git a/rules/integrations/azure/credential_access_entra_id_brute_force_activity.toml b/rules/integrations/azure/credential_access_entra_id_brute_force_activity.toml index 3abce2efa05..2604dada32d 100644 --- a/rules/integrations/azure/credential_access_entra_id_brute_force_activity.toml +++ b/rules/integrations/azure/credential_access_entra_id_brute_force_activity.toml @@ -2,7 +2,7 @@ creation_date = "2024/09/06" integration = ["azure"] maturity = "production" -updated_date = "2025/09/26" +updated_date = "2025/10/01" [rule] author = ["Elastic"] @@ -23,10 +23,10 @@ from = "now-60m" interval = "15m" language = "esql" license = "Elastic License v2" -name = "Microsoft Entra ID Sign-In Brute Force Activity" +name = "Entra ID User Sign-in Brute Force Attempted" note = """## Triage and analysis -### Investigating Microsoft Entra ID Sign-In Brute Force Activity +### Investigating Entra ID User Sign-in Brute Force Attempted This rule detects brute-force authentication activity in Entra ID sign-in logs. It classifies failed sign-in attempts into behavior types such as password spraying, credential stuffing, or password guessing. The classification (`bf_type`) helps prioritize triage and incident response. diff --git a/rules/integrations/azure/credential_access_entra_id_excessive_account_lockouts.toml b/rules/integrations/azure/credential_access_entra_id_excessive_account_lockouts.toml index 6714355362f..38dfd2d93e0 100644 --- a/rules/integrations/azure/credential_access_entra_id_excessive_account_lockouts.toml +++ b/rules/integrations/azure/credential_access_entra_id_excessive_account_lockouts.toml @@ -2,7 +2,7 @@ creation_date = "2025/07/01" integration = ["azure"] maturity = "production" -updated_date = "2025/09/26" +updated_date = "2025/10/01" [rule] author = ["Elastic"] @@ -21,10 +21,10 @@ from = "now-60m" interval = "15m" language = "esql" license = "Elastic License v2" -name = "Microsoft Entra ID Exccessive Account Lockouts Detected" +name = "Entra ID Excessive Account Lockouts Detected" note = """## Triage and analysis -### Investigating Microsoft Entra ID Exccessive Account Lockouts Detected +### Investigating Entra ID Excessive Account Lockouts Detected This rule detects a high number of sign-in failures due to account lockouts (error code `50053`) in Microsoft Entra ID sign-in logs. These lockouts are typically caused by repeated authentication failures, often as a result of brute-force tactics such as password spraying, credential stuffing, or automated guessing. This detection is time-bucketed and aggregates attempts to identify bursts or coordinated campaigns targeting multiple users. diff --git a/rules/integrations/azure/credential_access_entra_signin_brute_force_microsoft_365.toml b/rules/integrations/azure/credential_access_entra_id_signin_brute_force_microsoft_365.toml similarity index 98% rename from rules/integrations/azure/credential_access_entra_signin_brute_force_microsoft_365.toml rename to rules/integrations/azure/credential_access_entra_id_signin_brute_force_microsoft_365.toml index b3d40b8ad2f..e30f2a6cc47 100644 --- a/rules/integrations/azure/credential_access_entra_signin_brute_force_microsoft_365.toml +++ b/rules/integrations/azure/credential_access_entra_id_signin_brute_force_microsoft_365.toml @@ -2,7 +2,7 @@ creation_date = "2024/09/06" integration = ["azure"] maturity = "production" -updated_date = "2025/09/26" +updated_date = "2025/10/01" [rule] author = ["Elastic"] @@ -23,10 +23,10 @@ from = "now-60m" interval = "15m" language = "esql" license = "Elastic License v2" -name = "Microsoft 365 Brute Force via Entra ID Sign-Ins" +name = "Entra ID Sign-in Brute Force Attempt (Microsoft 365)" note = """## Triage and analysis -### Investigating Microsoft 365 Brute Force via Entra ID Sign-Ins +### Investigating Entra ID Sign-in Brute Force Attempt (Microsoft 365) Identifies brute-force authentication activity against Microsoft 365 services using Entra ID sign-in logs. This detection groups and classifies failed sign-in attempts based on behavior indicative of password spraying, credential stuffing, or password guessing. The classification (`bf_type`) is included for immediate triage. diff --git a/rules/integrations/azure/credential_access_azure_entra_suspicious_signin.toml b/rules/integrations/azure/credential_access_entra_id_suspicious_signin.toml similarity index 97% rename from rules/integrations/azure/credential_access_azure_entra_suspicious_signin.toml rename to rules/integrations/azure/credential_access_entra_id_suspicious_signin.toml index c73e5035938..eb337a5fa05 100644 --- a/rules/integrations/azure/credential_access_azure_entra_suspicious_signin.toml +++ b/rules/integrations/azure/credential_access_entra_id_suspicious_signin.toml @@ -2,7 +2,7 @@ creation_date = "2025/04/28" integration = ["azure"] maturity = "production" -updated_date = "2025/09/30" +updated_date = "2025/10/01" [rule] author = ["Elastic"] @@ -20,10 +20,10 @@ false_positives = [ from = "now-60m" language = "esql" license = "Elastic License v2" -name = "Microsoft Entra ID Concurrent Sign-Ins with Suspicious Properties" +name = "Entra ID Concurrent Sign-in with Suspicious Properties" note = """## Triage and analysis -### Investigating Microsoft Entra ID Concurrent Sign-Ins with Suspicious Properties +### Investigating Entra ID Concurrent Sign-in with Suspicious Properties ### Possible investigation steps diff --git a/rules/integrations/azure/credential_access_azure_entra_totp_brute_force_attempts.toml b/rules/integrations/azure/credential_access_entra_id_totp_brute_force_attempts.toml similarity index 98% rename from rules/integrations/azure/credential_access_azure_entra_totp_brute_force_attempts.toml rename to rules/integrations/azure/credential_access_entra_id_totp_brute_force_attempts.toml index dd2966dac7e..8f032f4c648 100644 --- a/rules/integrations/azure/credential_access_azure_entra_totp_brute_force_attempts.toml +++ b/rules/integrations/azure/credential_access_entra_id_totp_brute_force_attempts.toml @@ -2,7 +2,7 @@ creation_date = "2024/12/11" integration = ["azure"] maturity = "production" -updated_date = "2025/09/26" +updated_date = "2025/10/01" [rule] author = ["Elastic"] @@ -21,10 +21,10 @@ false_positives = [ from = "now-9m" language = "esql" license = "Elastic License v2" -name = "Microsoft Entra ID MFA TOTP Brute Force Attempts" +name = "Entra ID MFA TOTP Brute Force Attempted" note = """## Triage and analysis -### Investigating Microsoft Entra ID MFA TOTP Brute Force Attempts +### Investigating Entra ID MFA TOTP Brute Force Attempted This rule detects brute force attempts against Azure Entra multi-factor authentication (MFA) Time-based One-Time Password (TOTP) verification codes. It identifies high-frequency failed TOTP code attempts for a single user in a short time-span with a high number of distinct session IDs. Adversaries may programmatically attempt to brute-force TOTP codes by generating several sessions and attempting to guess the correct code. diff --git a/rules/integrations/azure/credential_access_azure_key_vault_excessive_retrieval.toml b/rules/integrations/azure/credential_access_key_vault_excessive_retrieval.toml similarity index 98% rename from rules/integrations/azure/credential_access_azure_key_vault_excessive_retrieval.toml rename to rules/integrations/azure/credential_access_key_vault_excessive_retrieval.toml index 80e01f97052..4e6cd30d07f 100644 --- a/rules/integrations/azure/credential_access_azure_key_vault_excessive_retrieval.toml +++ b/rules/integrations/azure/credential_access_key_vault_excessive_retrieval.toml @@ -2,7 +2,7 @@ creation_date = "2025/07/10" integration = ["azure"] maturity = "production" -updated_date = "2025/09/26" +updated_date = "2025/10/01" [rule] author = ["Elastic"] @@ -30,10 +30,10 @@ from = "now-9m" interval = "8m" language = "esql" license = "Elastic License v2" -name = "Excessive Secret or Key Retrieval from Azure Key Vault" +name = "Azure Key Vault Excessive Secret or Key Retrieved" note = """## Triage and analysis -### Investigating Excessive Secret or Key Retrieval from Azure Key Vault +### Investigating Azure Key Vault Excessive Secret or Key Retrieved Azure Key Vault is a cloud service that safeguards encryption keys and secrets like certificates, connection strings, and passwords. It is crucial for managing sensitive data in Azure environments. Unauthorized modifications to Key Vaults can lead to data breaches or service disruptions. This rule detects excessive secret or key retrieval operations from Azure Key Vault, which may indicate potential abuse or unauthorized access attempts. diff --git a/rules/integrations/azure/credential_access_azure_key_vault_retrieval_from_rare_identity.toml b/rules/integrations/azure/credential_access_key_vault_retrieval_from_rare_identity.toml similarity index 98% rename from rules/integrations/azure/credential_access_azure_key_vault_retrieval_from_rare_identity.toml rename to rules/integrations/azure/credential_access_key_vault_retrieval_from_rare_identity.toml index d93f55ce5da..d419efd8514 100644 --- a/rules/integrations/azure/credential_access_azure_key_vault_retrieval_from_rare_identity.toml +++ b/rules/integrations/azure/credential_access_key_vault_retrieval_from_rare_identity.toml @@ -2,7 +2,7 @@ creation_date = "2025/07/10" integration = ["azure"] maturity = "production" -updated_date = "2025/07/22" +updated_date = "2025/10/01" [rule] author = ["Elastic"] @@ -30,10 +30,10 @@ from = "now-9m" index = ["filebeat-*", "logs-azure.platformlogs-*"] language = "kuery" license = "Elastic License v2" -name = "Azure Key Vault Secret Key Usage by Unusual Identity" +name = "Azure Key Vault Unusual Secret Key Usage" note = """## Triage and analysis -### Investigating Azure Key Vault Secret Key Usage by Unusual Identity +### Investigating Azure Key Vault Unusual Secret Key Usage Azure Key Vault is a cloud service that safeguards encryption keys and secrets like certificates, connection strings, and passwords. It is crucial for managing sensitive data in Azure environments. Unauthorized modifications to Key Vaults can lead to data breaches or service disruptions. This rule detects excessive secret or key retrieval operations from Azure Key Vault, which may indicate potential abuse or unauthorized access attempts. diff --git a/rules/integrations/azure/credential_access_azure_full_network_packet_capture_detected.toml b/rules/integrations/azure/credential_access_network_full_network_packet_capture_detected.toml similarity index 97% rename from rules/integrations/azure/credential_access_azure_full_network_packet_capture_detected.toml rename to rules/integrations/azure/credential_access_network_full_network_packet_capture_detected.toml index 6a87378f28a..26c967920e6 100644 --- a/rules/integrations/azure/credential_access_azure_full_network_packet_capture_detected.toml +++ b/rules/integrations/azure/credential_access_network_full_network_packet_capture_detected.toml @@ -2,7 +2,7 @@ creation_date = "2021/08/12" integration = ["azure"] maturity = "production" -updated_date = "2025/09/26" +updated_date = "2025/10/01" [rule] author = ["Austin Songer"] @@ -23,13 +23,13 @@ from = "now-9m" index = ["logs-azure.activitylogs-*", "filebeat-*"] language = "kuery" license = "Elastic License v2" -name = "Azure Full Network Packet Capture Detected" +name = "Azure VNet Full Network Packet Capture Enabled" 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 Full Network Packet Capture Detected +### Investigating Azure VNet Full Network Packet Capture Enabled Azure's Packet Capture is a feature of Network Watcher that allows for the inspection of network traffic, useful for diagnosing network issues. However, if misused, it can capture sensitive data from unencrypted traffic, posing a security risk. Adversaries might exploit this to access credentials or other sensitive information. The detection rule identifies suspicious packet capture activities by monitoring specific Azure activity logs for successful operations, helping to flag potential misuse. diff --git a/rules/integrations/azure/defense_evasion_azure_automation_runbook_deleted.toml b/rules/integrations/azure/defense_evasion_automation_runbook_deleted.toml similarity index 100% rename from rules/integrations/azure/defense_evasion_azure_automation_runbook_deleted.toml rename to rules/integrations/azure/defense_evasion_automation_runbook_deleted.toml diff --git a/rules/integrations/azure/defense_evasion_event_hub_deletion.toml b/rules/integrations/azure/defense_evasion_event_hub_deletion.toml index 54dcf6f5447..011c377ec17 100644 --- a/rules/integrations/azure/defense_evasion_event_hub_deletion.toml +++ b/rules/integrations/azure/defense_evasion_event_hub_deletion.toml @@ -2,7 +2,7 @@ creation_date = "2020/08/18" integration = ["azure"] maturity = "production" -updated_date = "2025/09/30" +updated_date = "2025/10/01" [rule] author = ["Elastic"] @@ -21,13 +21,13 @@ from = "now-9m" index = ["logs-azure.activitylogs-*", "filebeat-*"] language = "kuery" license = "Elastic License v2" -name = "Azure Event Hub Deletion" +name = "Azure Event Hub Deleted" 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 Event Hub Deletion +### Investigating Azure Event Hub Deleted Azure Event Hub is a scalable data streaming platform and event ingestion service, crucial for processing large volumes of data in real-time. Adversaries may target Event Hubs to delete them, aiming to disrupt data flow and evade detection by erasing evidence of their activities. The detection rule monitors Azure activity logs for successful deletion operations, flagging potential defense evasion attempts by identifying unauthorized or suspicious deletions. diff --git a/rules/integrations/azure/defense_evasion_azure_diagnostic_settings_deletion.toml b/rules/integrations/azure/defense_evasion_insights_diagnostic_settings_deletion.toml similarity index 97% rename from rules/integrations/azure/defense_evasion_azure_diagnostic_settings_deletion.toml rename to rules/integrations/azure/defense_evasion_insights_diagnostic_settings_deletion.toml index ae8cb40322a..449330a161c 100644 --- a/rules/integrations/azure/defense_evasion_azure_diagnostic_settings_deletion.toml +++ b/rules/integrations/azure/defense_evasion_insights_diagnostic_settings_deletion.toml @@ -2,7 +2,7 @@ creation_date = "2020/08/17" integration = ["azure"] maturity = "production" -updated_date = "2025/09/30" +updated_date = "2025/10/01" [rule] author = ["Elastic"] @@ -22,13 +22,13 @@ from = "now-9m" index = ["logs-azure.activitylogs-*", "filebeat-*"] language = "kuery" license = "Elastic License v2" -name = "Azure Diagnostic Settings Deletion" +name = "Azure Diagnostic Settings Settings Deleted" 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 Diagnostic Settings Deletion +### Investigating Azure Diagnostic Settings Settings Deleted Azure Diagnostic Settings are crucial for monitoring and logging platform activities, sending data to various destinations for analysis. Adversaries may delete these settings to hinder detection and analysis of their activities, effectively evading defenses. The detection rule identifies such deletions by monitoring specific Azure activity logs for successful deletion operations, flagging potential defense evasion attempts. diff --git a/rules/integrations/azure/defense_evasion_kubernetes_events_deleted.toml b/rules/integrations/azure/defense_evasion_kubernetes_events_deleted.toml index cb4039ba65b..7c81a911dff 100644 --- a/rules/integrations/azure/defense_evasion_kubernetes_events_deleted.toml +++ b/rules/integrations/azure/defense_evasion_kubernetes_events_deleted.toml @@ -2,7 +2,7 @@ creation_date = "2021/06/24" integration = ["azure"] maturity = "production" -updated_date = "2025/09/26" +updated_date = "2025/10/01" [rule] author = ["Austin Songer"] @@ -22,13 +22,13 @@ from = "now-9m" index = ["logs-azure.activitylogs-*", "filebeat-*"] language = "kuery" license = "Elastic License v2" -name = "Azure Kubernetes Events Deleted" +name = "Azure Kubernetes Services (AKS) Kubernetes Events Deleted" 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 Kubernetes Events Deleted +### Investigating Azure Kubernetes Services (AKS) Kubernetes Events Deleted Azure Kubernetes Service (AKS) manages containerized applications using Kubernetes, which logs events like state changes. These logs are crucial for monitoring and troubleshooting. Adversaries may delete these logs to hide their tracks, impairing defenses. The detection rule identifies such deletions by monitoring specific Azure activity logs, flagging successful deletion operations to alert security teams of potential evasion tactics. diff --git a/rules/integrations/azure/defense_evasion_firewall_policy_deletion.toml b/rules/integrations/azure/defense_evasion_network_firewall_policy_deletion.toml similarity index 98% rename from rules/integrations/azure/defense_evasion_firewall_policy_deletion.toml rename to rules/integrations/azure/defense_evasion_network_firewall_policy_deletion.toml index 659abcd7089..760f694214b 100644 --- a/rules/integrations/azure/defense_evasion_firewall_policy_deletion.toml +++ b/rules/integrations/azure/defense_evasion_network_firewall_policy_deletion.toml @@ -2,7 +2,7 @@ creation_date = "2020/08/18" integration = ["azure"] maturity = "production" -updated_date = "2025/09/30" +updated_date = "2025/10/01" [rule] author = ["Elastic"] @@ -21,13 +21,13 @@ from = "now-9m" index = ["logs-azure.activitylogs-*", "filebeat-*"] language = "kuery" license = "Elastic License v2" -name = "Azure Firewall Policy Deletion" +name = "Azure VNet Firewall Policy Deleted" 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 Firewall Policy Deletion +### Investigating Azure VNet Firewall Policy Deleted Azure Firewall policies are crucial for managing and enforcing network security rules across Azure environments. Adversaries may target these policies to disable security measures, facilitating unauthorized access or data exfiltration. The detection rule monitors Azure activity logs for successful deletion operations of firewall policies, signaling potential defense evasion attempts by identifying specific operation names and outcomes. diff --git a/rules/integrations/azure/defense_evasion_frontdoor_firewall_policy_deletion.toml b/rules/integrations/azure/defense_evasion_network_frontdoor_firewall_policy_deletion.toml similarity index 90% rename from rules/integrations/azure/defense_evasion_frontdoor_firewall_policy_deletion.toml rename to rules/integrations/azure/defense_evasion_network_frontdoor_firewall_policy_deletion.toml index fdb6e86d150..816cff08159 100644 --- a/rules/integrations/azure/defense_evasion_frontdoor_firewall_policy_deletion.toml +++ b/rules/integrations/azure/defense_evasion_network_frontdoor_firewall_policy_deletion.toml @@ -2,7 +2,7 @@ creation_date = "2021/08/01" integration = ["azure"] maturity = "production" -updated_date = "2025/09/30" +updated_date = "2025/10/01" [rule] author = ["Austin Songer"] @@ -23,15 +23,15 @@ from = "now-9m" index = ["logs-azure.activitylogs-*", "filebeat-*"] language = "kuery" license = "Elastic License v2" -name = "Azure Frontdoor Web Application Firewall (WAF) Policy Deleted" +name = "Azure VNet Firewall Front Door WAF Policy Deleted" 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 Frontdoor Web Application Firewall (WAF) Policy Deleted +### Investigating Azure VNet Firewall Front Door WAF Policy Deleted -Azure Frontdoor WAF policies are crucial for protecting web applications by filtering and monitoring HTTP requests to block malicious traffic. Adversaries may delete these policies to bypass security measures, facilitating unauthorized access or data exfiltration. The detection rule identifies such deletions by monitoring Azure activity logs for specific delete operations, signaling potential defense evasion attempts. +Azure Front Door WAF policies are crucial for protecting web applications by filtering and monitoring HTTP requests to block malicious traffic. Adversaries may delete these policies to bypass security measures, facilitating unauthorized access or data exfiltration. The detection rule identifies such deletions by monitoring Azure activity logs for specific delete operations, signaling potential defense evasion attempts. ### Possible investigation steps diff --git a/rules/integrations/azure/defense_evasion_network_watcher_deletion.toml b/rules/integrations/azure/defense_evasion_network_watcher_deletion.toml index 8ede33b29b2..8d95497fea0 100644 --- a/rules/integrations/azure/defense_evasion_network_watcher_deletion.toml +++ b/rules/integrations/azure/defense_evasion_network_watcher_deletion.toml @@ -2,7 +2,7 @@ creation_date = "2020/08/31" integration = ["azure"] maturity = "production" -updated_date = "2025/09/26" +updated_date = "2025/10/01" [rule] author = ["Elastic"] @@ -22,13 +22,13 @@ from = "now-9m" index = ["logs-azure.activitylogs-*", "filebeat-*"] language = "kuery" license = "Elastic License v2" -name = "Azure Network Watcher Deletion" +name = "Azure VNet Network Watcher Deleted" 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 Network Watcher Deletion +### Investigating Azure VNet Network Watcher Deleted Azure Network Watcher is a vital tool for monitoring and diagnosing network issues within Azure environments. It provides insights and logging capabilities crucial for maintaining network security. Adversaries may delete Network Watchers to disable these monitoring functions, thereby evading detection. The detection rule identifies such deletions by monitoring Azure activity logs for specific delete operations, flagging successful attempts as potential security threats. diff --git a/rules/integrations/azure/defense_evasion_suppression_rule_created.toml b/rules/integrations/azure/defense_evasion_security_alert_suppression_rule_created.toml similarity index 97% rename from rules/integrations/azure/defense_evasion_suppression_rule_created.toml rename to rules/integrations/azure/defense_evasion_security_alert_suppression_rule_created.toml index 33133ba71ba..c3a8af7af73 100644 --- a/rules/integrations/azure/defense_evasion_suppression_rule_created.toml +++ b/rules/integrations/azure/defense_evasion_security_alert_suppression_rule_created.toml @@ -2,7 +2,7 @@ creation_date = "2021/08/27" integration = ["azure"] maturity = "production" -updated_date = "2025/09/26" +updated_date = "2025/10/01" [rule] author = ["Austin Songer"] @@ -22,13 +22,13 @@ from = "now-9m" index = ["logs-azure.activitylogs-*", "filebeat-*"] language = "kuery" license = "Elastic License v2" -name = "Azure Alert Suppression Rule Created or Modified" +name = "Azure Diagnostic Settings Alert Suppression Rule Created or Modified" 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 Alert Suppression Rule Created or Modified +### Investigating Azure Diagnostic Settings Alert Suppression Rule Created or Modified Azure Alert Suppression Rules are used to manage alert noise by filtering out known false positives. However, adversaries can exploit these rules to hide malicious activities by suppressing legitimate security alerts. The detection rule monitors Azure activity logs for successful operations related to suppression rule changes, helping identify potential misuse that could lead to defense evasion and reduced security visibility. diff --git a/rules/integrations/azure/defense_evasion_azure_blob_permissions_modified.toml b/rules/integrations/azure/defense_evasion_storage_blob_permissions_modified.toml similarity index 97% rename from rules/integrations/azure/defense_evasion_azure_blob_permissions_modified.toml rename to rules/integrations/azure/defense_evasion_storage_blob_permissions_modified.toml index 5a1294e7a65..42ca53e61c5 100644 --- a/rules/integrations/azure/defense_evasion_azure_blob_permissions_modified.toml +++ b/rules/integrations/azure/defense_evasion_storage_blob_permissions_modified.toml @@ -2,7 +2,7 @@ creation_date = "2021/09/22" integration = ["azure"] maturity = "production" -updated_date = "2025/09/26" +updated_date = "2025/10/01" [rule] author = ["Austin Songer"] @@ -21,13 +21,13 @@ from = "now-9m" index = ["logs-azure.activitylogs-*", "filebeat-*"] language = "kuery" license = "Elastic License v2" -name = "Azure Blob Permissions Modification" +name = "Azure Blob Storage Permissions Modified" 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 Blob Permissions Modification +### Investigating Azure Blob Storage Permissions Modified Azure Blob Storage is a service for storing large amounts of unstructured data. It uses Azure RBAC to manage access, ensuring only authorized users can modify or access data. Adversaries may exploit this by altering permissions to gain unauthorized access or disrupt operations. The detection rule monitors specific Azure activity logs for successful permission changes, alerting analysts to potential security breaches or misconfigurations. diff --git a/rules/integrations/azure/discovery_bloodhound_user_agents_detected.toml b/rules/integrations/azure/discovery_bloodhound_user_agents_detected.toml index 402945fecc1..4f6ed99d619 100644 --- a/rules/integrations/azure/discovery_bloodhound_user_agents_detected.toml +++ b/rules/integrations/azure/discovery_bloodhound_user_agents_detected.toml @@ -2,7 +2,7 @@ creation_date = "2025/06/03" integration = ["azure", "o365"] maturity = "production" -updated_date = "2025/06/03" +updated_date = "2025/10/01" [rule] author = ["Elastic"] @@ -27,7 +27,7 @@ from = "now-9m" index = ["filebeat-*", "logs-azure.*", "logs-o365.audit-*"] language = "eql" license = "Elastic License v2" -name = "BloodHound Suite User-Agents Detected" +name = "Entra ID Sign-in BloodHound Suite User-Agent Detected" note = """## Triage and analysis This rule identifies potential enumeration activity using AzureHound, SharpHound, or BloodHound across Microsoft cloud services. These tools are often used by red teamers and adversaries to map users, groups, roles, applications, and access relationships within Microsoft Entra ID (Azure AD) and Microsoft 365. diff --git a/rules/integrations/azure/discovery_teamfiltration_user_agents_detected.toml b/rules/integrations/azure/discovery_entra_id_teamfiltration_user_agents_detected.toml similarity index 98% rename from rules/integrations/azure/discovery_teamfiltration_user_agents_detected.toml rename to rules/integrations/azure/discovery_entra_id_teamfiltration_user_agents_detected.toml index 970fdb2ec0a..2720ed378d5 100644 --- a/rules/integrations/azure/discovery_teamfiltration_user_agents_detected.toml +++ b/rules/integrations/azure/discovery_entra_id_teamfiltration_user_agents_detected.toml @@ -2,7 +2,7 @@ creation_date = "2025/07/02" integration = ["azure", "o365"] maturity = "production" -updated_date = "2025/07/02" +updated_date = "2025/10/01" [rule] author = ["Elastic"] @@ -29,7 +29,7 @@ from = "now-9m" index = ["filebeat-*", "logs-azure.signinlogs-*", "logs-o365.audit-*"] language = "kuery" license = "Elastic License v2" -name = "TeamFiltration User-Agents Detected" +name = "Entra ID Sign-in TeamFiltration User-Agent Detected" note = """## Triage and analysis Identifies potential enumeration or password spraying activity using TeamFiltration tool. TeamFiltration is an open-source enumeration, password spraying and exfiltration tool designed for Entra ID and Microsoft 365. Adversaries are known to use TeamFiltration in-the-wild to enumerate users, groups, and roles, as well as to perform password spraying attacks against Microsoft Entra ID and Microsoft 365 accounts. This rule detects the use of TeamFiltration by monitoring for specific user-agent strings associated with the tool in Azure and Microsoft 365 logs. diff --git a/rules/integrations/azure/discovery_blob_container_access_mod.toml b/rules/integrations/azure/discovery_storage_blob_container_access_modification.toml similarity index 97% rename from rules/integrations/azure/discovery_blob_container_access_mod.toml rename to rules/integrations/azure/discovery_storage_blob_container_access_modification.toml index 55ec8eb4d50..d64573ecb1a 100644 --- a/rules/integrations/azure/discovery_blob_container_access_mod.toml +++ b/rules/integrations/azure/discovery_storage_blob_container_access_modification.toml @@ -2,7 +2,7 @@ creation_date = "2020/08/20" integration = ["azure"] maturity = "production" -updated_date = "2025/09/30" +updated_date = "2025/10/01" [rule] author = ["Elastic"] @@ -21,13 +21,13 @@ from = "now-9m" index = ["logs-azure.activitylogs-*", "filebeat-*"] language = "kuery" license = "Elastic License v2" -name = "Azure Blob Container Access Level Modification" +name = "Azure Blob Storage Container Access Level Modified" 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 Blob Container Access Level Modification +### Investigating Azure Blob Storage Container Access Level Modified Azure Blob Storage is a service for storing large amounts of unstructured data, where access levels can be configured to control data visibility. Adversaries may exploit misconfigured access levels to gain unauthorized access to sensitive data. The detection rule monitors changes in container access settings, focusing on successful modifications, to identify potential security risks associated with unauthorized access level changes. diff --git a/rules/integrations/azure/execution_azure_automation_runbook_created_or_modified.toml b/rules/integrations/azure/execution_automation_runbook_created_or_modified.toml similarity index 100% rename from rules/integrations/azure/execution_azure_automation_runbook_created_or_modified.toml rename to rules/integrations/azure/execution_automation_runbook_created_or_modified.toml diff --git a/rules/integrations/azure/execution_command_virtual_machine.toml b/rules/integrations/azure/execution_compute_vm_command_executed.toml similarity index 97% rename from rules/integrations/azure/execution_command_virtual_machine.toml rename to rules/integrations/azure/execution_compute_vm_command_executed.toml index ba5780f2239..02c9e48298f 100644 --- a/rules/integrations/azure/execution_command_virtual_machine.toml +++ b/rules/integrations/azure/execution_compute_vm_command_executed.toml @@ -2,7 +2,7 @@ creation_date = "2020/08/17" integration = ["azure"] maturity = "production" -updated_date = "2025/09/30" +updated_date = "2025/10/01" [rule] author = ["Elastic"] @@ -24,13 +24,13 @@ from = "now-9m" index = ["logs-azure.activitylogs-*", "filebeat-*"] language = "kuery" license = "Elastic License v2" -name = "Azure Command Execution on Virtual Machine" +name = "Azure Compute VM Command Executed" 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 +### Investigating Azure Compute VM Command Executed 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. diff --git a/rules/integrations/azure/impact_azure_key_vault_modified.toml b/rules/integrations/azure/impact_key_vault_modified_by_unusual_user.toml similarity index 100% rename from rules/integrations/azure/impact_azure_key_vault_modified.toml rename to rules/integrations/azure/impact_key_vault_modified_by_unusual_user.toml diff --git a/rules/integrations/azure/impact_kubernetes_pod_deleted.toml b/rules/integrations/azure/impact_kubernetes_pod_deleted.toml index 6badbeb8f3e..385f33cde9d 100644 --- a/rules/integrations/azure/impact_kubernetes_pod_deleted.toml +++ b/rules/integrations/azure/impact_kubernetes_pod_deleted.toml @@ -2,7 +2,7 @@ creation_date = "2021/06/24" integration = ["azure"] maturity = "production" -updated_date = "2025/09/30" +updated_date = "2025/10/01" [rule] author = ["Austin Songer"] @@ -21,13 +21,13 @@ from = "now-9m" index = ["logs-azure.activitylogs-*", "filebeat-*"] language = "kuery" license = "Elastic License v2" -name = "Azure Kubernetes Pods Deleted" +name = "Azure Kubernetes Services (AKS) Kubernetes Pods Deleted" 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 Kubernetes Pods Deleted +### Investigating Azure Kubernetes Services (AKS) Kubernetes Pods Deleted Azure Kubernetes Service (AKS) enables the deployment, management, and scaling of containerized applications using Kubernetes. Pods, the smallest deployable units in Kubernetes, can be targeted by adversaries to disrupt services or evade detection. Malicious actors might delete pods to cause downtime or hide their activities. The detection rule monitors Azure activity logs for successful pod deletion operations, alerting security teams to potential unauthorized actions that could impact the environment's stability and security. diff --git a/rules/integrations/azure/impact_resource_group_deletion.toml b/rules/integrations/azure/impact_resources_resource_group_deletion.toml similarity index 98% rename from rules/integrations/azure/impact_resource_group_deletion.toml rename to rules/integrations/azure/impact_resources_resource_group_deletion.toml index f04a52593d5..4cffe3fbd1d 100644 --- a/rules/integrations/azure/impact_resource_group_deletion.toml +++ b/rules/integrations/azure/impact_resources_resource_group_deletion.toml @@ -2,7 +2,7 @@ creation_date = "2020/08/17" integration = ["azure"] maturity = "production" -updated_date = "2025/09/26" +updated_date = "2025/10/01" [rule] author = ["Elastic"] @@ -23,13 +23,13 @@ from = "now-9m" index = ["logs-azure.activitylogs-*", "filebeat-*"] language = "kuery" license = "Elastic License v2" -name = "Azure Resource Group Deletion" +name = "Azure Resource Group Deleted" 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 Resource Group Deletion +### Investigating Azure Resource Group Deleted Azure Resource Groups are containers that hold related resources for an Azure solution, enabling efficient management and organization. Adversaries may exploit this by deleting entire groups to disrupt services or erase data, causing significant impact. The detection rule monitors Azure activity logs for successful deletion operations, flagging potential malicious actions for further investigation. diff --git a/rules/integrations/azure/initial_access_entra_id_device_code_auth_with_broker_client.toml b/rules/integrations/azure/initial_access_entra_id_device_code_auth_with_broker_client.toml index 7dbd4b00ba2..4b533314a4f 100644 --- a/rules/integrations/azure/initial_access_entra_id_device_code_auth_with_broker_client.toml +++ b/rules/integrations/azure/initial_access_entra_id_device_code_auth_with_broker_client.toml @@ -2,7 +2,7 @@ creation_date = "2024/06/24" integration = ["azure"] maturity = "production" -updated_date = "2025/09/26" +updated_date = "2025/10/01" [rule] author = ["Elastic"] @@ -13,7 +13,7 @@ from = "now-9m" index = ["filebeat-*", "logs-azure.signinlogs-*", "logs-azure.activitylogs-*"] language = "kuery" license = "Elastic License v2" -name = "Entra ID Device Code Auth with Broker Client" +name = "Entra ID OAuth Device Code Grant by Microsoft Authentication Broker" references =[ "https://dirkjanm.io/assets/raw/Phishing%20the%20Phishing%20Resistant.pdf", "https://learn.microsoft.com/en-us/troubleshoot/azure/entra/entra-id/governance/verify-first-party-apps-sign-in", @@ -49,7 +49,7 @@ 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 Entra ID Device Code Auth with Broker Client +### Investigating Entra ID OAuth Device Code Grant by Microsoft Authentication Broker Entra ID Device Code Authentication allows users to authenticate devices using a code, facilitating seamless access to Azure resources. Adversaries exploit this by compromising Primary Refresh Tokens (PRTs) to bypass multi-factor authentication and Conditional Access policies. The detection rule identifies unauthorized access attempts by monitoring successful sign-ins using device code authentication linked to a specific broker client application ID, flagging potential misuse. diff --git a/rules/integrations/azure/initial_access_external_guest_user_invite.toml b/rules/integrations/azure/initial_access_entra_id_external_guest_user_invite.toml similarity index 97% rename from rules/integrations/azure/initial_access_external_guest_user_invite.toml rename to rules/integrations/azure/initial_access_entra_id_external_guest_user_invite.toml index 500ea8310e4..d1191e4c926 100644 --- a/rules/integrations/azure/initial_access_external_guest_user_invite.toml +++ b/rules/integrations/azure/initial_access_entra_id_external_guest_user_invite.toml @@ -2,7 +2,7 @@ creation_date = "2020/08/31" integration = ["azure"] maturity = "production" -updated_date = "2025/09/26" +updated_date = "2025/10/01" [rule] author = ["Elastic"] @@ -23,13 +23,13 @@ from = "now-9m" index = ["logs-azure.auditlogs-*", "filebeat-*"] language = "kuery" license = "Elastic License v2" -name = "Azure External Guest User Invitation" +name = "Entra ID External Guest User Invited" 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 External Guest User Invitation +### Investigating Entra ID External Guest User Invited Azure Active Directory (AD) facilitates collaboration by allowing external users to be invited as guest users, enhancing flexibility in cloud environments. However, adversaries may exploit this feature to gain unauthorized access, posing security risks. The detection rule monitors audit logs for successful external user invitations, flagging potential misuse by identifying unusual or unnecessary guest account creations. diff --git a/rules/integrations/azure/initial_access_first_time_seen_device_code_auth.toml b/rules/integrations/azure/initial_access_entra_id_first_time_seen_device_code_auth.toml similarity index 97% rename from rules/integrations/azure/initial_access_first_time_seen_device_code_auth.toml rename to rules/integrations/azure/initial_access_entra_id_first_time_seen_device_code_auth.toml index a2d131dbb6c..f110f617ac7 100644 --- a/rules/integrations/azure/initial_access_first_time_seen_device_code_auth.toml +++ b/rules/integrations/azure/initial_access_entra_id_first_time_seen_device_code_auth.toml @@ -2,7 +2,7 @@ creation_date = "2024/10/14" integration = ["azure"] maturity = "production" -updated_date = "2025/09/26" +updated_date = "2025/10/01" [rule] author = ["Elastic", "Matteo Potito Giorgio"] @@ -16,10 +16,10 @@ from = "now-9m" index = ["filebeat-*", "logs-azure.signinlogs-*", "logs-azure.activitylogs-*"] language = "kuery" license = "Elastic License v2" -name = "First Occurrence of Entra ID Auth via DeviceCode Protocol" +name = "Entra ID OAuth Device Code Grant by Unusual User" note = """## Triage and analysis -### Investigating First Occurrence of Entra ID Auth via DeviceCode Protocol +### Investigating Entra ID OAuth Device Code Grant by Unusual User This rule detects the first instance of a user authenticating via the **DeviceCode** authentication protocol within a **14-day window**. The **DeviceCode** authentication workflow is designed for devices that lack keyboards, such as IoT devices and smart TVs. However, adversaries can abuse this mechanism by phishing users and stealing authentication tokens, leading to unauthorized access. diff --git a/rules/integrations/azure/initial_access_entra_graph_single_session_from_multiple_addresses.toml b/rules/integrations/azure/initial_access_entra_id_graph_single_session_from_multiple_addresses.toml similarity index 98% rename from rules/integrations/azure/initial_access_entra_graph_single_session_from_multiple_addresses.toml rename to rules/integrations/azure/initial_access_entra_id_graph_single_session_from_multiple_addresses.toml index 59141ad8430..9a383918a3d 100644 --- a/rules/integrations/azure/initial_access_entra_graph_single_session_from_multiple_addresses.toml +++ b/rules/integrations/azure/initial_access_entra_id_graph_single_session_from_multiple_addresses.toml @@ -2,7 +2,7 @@ creation_date = "2025/05/08" integration = ["azure"] maturity = "production" -updated_date = "2025/08/20" +updated_date = "2025/10/01" [rule] author = ["Elastic"] @@ -24,10 +24,10 @@ from = "now-31m" interval = "30m" language = "esql" license = "Elastic License v2" -name = "Microsoft Entra ID Suspicious Session Reuse to Graph Access" +name = "Entra ID OAuth User Impersonation to Microsoft Graph" note = """## Triage and analysis -### Investigating Microsoft Entra ID Suspicious Session Reuse to Graph Access +### Investigating Entra ID OAuth User Impersonation to Microsoft Graph Identifies potential phishing, session hijacking or token replay in Microsoft Entra ID. This rule detects cases where a user signs in and subsequently accesses Microsoft Graph from a different IP address using the same session ID and client application. This may indicate a successful OAuth phishing attack, session hijacking, or token replay attack, where an adversary has stolen a session cookie or refresh/access token and is impersonating the user from an alternate host or location. diff --git a/rules/integrations/azure/initial_access_entra_id_high_risk_signin.toml b/rules/integrations/azure/initial_access_entra_id_high_risk_signin.toml index 0509c5e3a9f..aad54418139 100644 --- a/rules/integrations/azure/initial_access_entra_id_high_risk_signin.toml +++ b/rules/integrations/azure/initial_access_entra_id_high_risk_signin.toml @@ -2,7 +2,7 @@ creation_date = "2021/01/04" integration = ["azure"] maturity = "production" -updated_date = "2025/09/30" +updated_date = "2025/10/01" [rule] author = ["Elastic", "Willem D'Haese"] @@ -16,10 +16,10 @@ from = "now-9m" index = ["filebeat-*", "logs-azure.signinlogs-*"] language = "kuery" license = "Elastic License v2" -name = "Microsoft Entra ID High Risk Sign-in" +name = "Entra ID High Risk Sign-in" note = """## Triage and analysis -### Investigating Microsoft Entra ID High Risk Sign-in +### Investigating Entra ID High Risk Sign-in This rule detects high-risk sign-ins in Microsoft Entra ID as identified by Identity Protection. These sign-ins are flagged with a risk level of `high` during the authentication process, indicating a strong likelihood of compromise based on Microsoft’s machine learning and heuristics. This alert is valuable for identifying accounts under active attack or compromise using valid credentials. diff --git a/rules/integrations/azure/initial_access_entra_illicit_consent_grant_via_registered_application.toml b/rules/integrations/azure/initial_access_entra_id_illicit_consent_grant_via_registered_application.toml similarity index 97% rename from rules/integrations/azure/initial_access_entra_illicit_consent_grant_via_registered_application.toml rename to rules/integrations/azure/initial_access_entra_id_illicit_consent_grant_via_registered_application.toml index 2957e61e3d0..8135dd56043 100644 --- a/rules/integrations/azure/initial_access_entra_illicit_consent_grant_via_registered_application.toml +++ b/rules/integrations/azure/initial_access_entra_id_illicit_consent_grant_via_registered_application.toml @@ -2,7 +2,7 @@ creation_date = "2020/09/01" integration = ["azure"] maturity = "production" -updated_date = "2025/09/26" +updated_date = "2025/10/01" [rule] author = ["Elastic"] @@ -16,10 +16,10 @@ from = "now-9m" index = ["logs-azure.auditlogs-*"] language = "kuery" license = "Elastic License v2" -name = "Microsoft Entra ID Illicit Consent Grant via Registered Application" +name = "Entra ID Illicit Consent Grant via Registered Application" note = """## Triage and analysis -### Investigating Microsoft Entra ID Illicit Consent Grant via Registered Application +### Investigating Entra ID Illicit Consent Grant via Registered Application Adversaries may register a malicious application in Microsoft Entra ID and trick users into granting excessive permissions via OAuth consent. These applications can access sensitive data—such as mail, profiles, or files—on behalf of the user once consent is granted. This is commonly delivered via spearphishing links that prompt users to approve permissions for seemingly legitimate applications. diff --git a/rules/integrations/azure/initial_access_entra_oauth_phishing_via_vscode_client.toml b/rules/integrations/azure/initial_access_entra_id_oauth_phishing_via_vscode_client.toml similarity index 97% rename from rules/integrations/azure/initial_access_entra_oauth_phishing_via_vscode_client.toml rename to rules/integrations/azure/initial_access_entra_id_oauth_phishing_via_vscode_client.toml index 0c202b8a455..6415e4d722e 100644 --- a/rules/integrations/azure/initial_access_entra_oauth_phishing_via_vscode_client.toml +++ b/rules/integrations/azure/initial_access_entra_id_oauth_phishing_via_vscode_client.toml @@ -2,7 +2,7 @@ creation_date = "2025/04/23" integration = ["azure"] maturity = "production" -updated_date = "2025/09/30" +updated_date = "2025/10/01" [rule] author = ["Elastic"] @@ -19,10 +19,10 @@ from = "now-9m" index = ["filebeat-*", "logs-azure.signinlogs-*"] language = "kuery" license = "Elastic License v2" -name = "Microsoft Entra ID OAuth Phishing via Visual Studio Code Client" +name = "Entra ID OAuth Flow by Visual Studio Code to Microsoft Graph" note = """## Triage and analysis -### Investigating Microsoft Entra ID OAuth Phishing via Visual Studio Code Client +### Investigating Entra ID OAuth Flow by Visual Studio Code to Microsoft Graph ### Possible investigation steps diff --git a/rules/integrations/azure/initial_access_entra_id_oauth_user_impersonation_scope.toml b/rules/integrations/azure/initial_access_entra_id_oauth_user_impersonation_scope.toml index d0b2c8b021f..c7a55cd37ee 100644 --- a/rules/integrations/azure/initial_access_entra_id_oauth_user_impersonation_scope.toml +++ b/rules/integrations/azure/initial_access_entra_id_oauth_user_impersonation_scope.toml @@ -2,7 +2,7 @@ creation_date = "2025/07/03" integration = ["azure"] maturity = "production" -updated_date = "2025/09/26" +updated_date = "2025/09/30" [rule] author = ["Elastic"] @@ -18,10 +18,10 @@ from = "now-9m" index = ["filebeat-*", "logs-azure.signinlogs-*"] language = "kuery" license = "Elastic License v2" -name = "Suspicious Entra ID OAuth User Impersonation Scope Detected" +name = "Entra ID OAuth User Impersonation by Client" note = """## Triage and Analysis -### Investigating Suspicious Entra ID OAuth User Impersonation Scope Detected +### Investigating Entra ID OAuth User Impersonation by Client Identifies rare occurrences of OAuth workflow for a user principal that is single factor authenticated, with an OAuth scope containing `user_impersonation`, and a token issuer type of `AzureAD`. This rule is designed to detect suspicious OAuth user impersonation attempts in Microsoft Entra ID, particularly those involving the `user_impersonation` scope, which is often used by adversaries to gain unauthorized access to user accounts. The rule focuses on sign-in events where diff --git a/rules/integrations/azure/initial_access_azure_active_directory_powershell_signin.toml b/rules/integrations/azure/initial_access_entra_id_powershell_signin.toml similarity index 97% rename from rules/integrations/azure/initial_access_azure_active_directory_powershell_signin.toml rename to rules/integrations/azure/initial_access_entra_id_powershell_signin.toml index 58320da8210..4be00e69f2b 100644 --- a/rules/integrations/azure/initial_access_azure_active_directory_powershell_signin.toml +++ b/rules/integrations/azure/initial_access_entra_id_powershell_signin.toml @@ -2,7 +2,7 @@ creation_date = "2020/12/14" integration = ["azure"] maturity = "production" -updated_date = "2025/09/30" +updated_date = "2025/10/01" [rule] author = ["Elastic"] @@ -21,10 +21,10 @@ from = "now-9m" index = ["logs-azure.signinlogs-*", "filebeat-*"] language = "kuery" license = "Elastic License v2" -name = "Azure Active Directory PowerShell Sign-in" +name = "Entra ID PowerShell Sign-in" note = """## Triage and analysis -### Investigating Azure Active Directory PowerShell Sign-in +### Investigating Entra ID PowerShell Sign-in Azure Active Directory PowerShell for Graph (Azure AD PowerShell) is a module IT professionals commonly use to manage their Azure Active Directory. The cmdlets in the Azure AD PowerShell module enable you to retrieve data from the directory, create new objects in the directory, update existing objects, remove objects, as well as configure the directory and its features. diff --git a/rules/integrations/azure/initial_access_entra_protection_multi_azure_identity_protection_alerts.toml b/rules/integrations/azure/initial_access_entra_id_protection_alerts_for_user.toml similarity index 96% rename from rules/integrations/azure/initial_access_entra_protection_multi_azure_identity_protection_alerts.toml rename to rules/integrations/azure/initial_access_entra_id_protection_alerts_for_user.toml index bdfc55dbb91..23ce97842ea 100644 --- a/rules/integrations/azure/initial_access_entra_protection_multi_azure_identity_protection_alerts.toml +++ b/rules/integrations/azure/initial_access_entra_id_protection_alerts_for_user.toml @@ -2,7 +2,7 @@ creation_date = "2025/04/30" integration = ["azure"] maturity = "production" -updated_date = "2025/09/08" +updated_date = "2025/10/01" [rule] author = ["Elastic"] @@ -16,10 +16,10 @@ from = "now-9m" index = ["logs-azure.identity_protection-*"] language = "eql" license = "Elastic License v2" -name = "Multiple Microsoft Entra ID Protection Alerts by User Principal" +name = "Entra ID Protection Alerts for User Detected" note = """## Triage and analysis -### Investigating Multiple Microsoft Entra ID Protection Alerts by User Principal +### Investigating Entra ID Protection Alerts for User Detected #### Possible investigation steps - Identify the Risk Detection that triggered the event. A list with descriptions can be found [here](https://docs.microsoft.com/en-us/azure/active-directory/identity-protection/concept-identity-protection-risks#risk-types-and-detection). diff --git a/rules/integrations/azure/initial_access_entra_rare_app_id_for_principal_auth.toml b/rules/integrations/azure/initial_access_entra_id_rare_app_id_for_principal_auth.toml similarity index 98% rename from rules/integrations/azure/initial_access_entra_rare_app_id_for_principal_auth.toml rename to rules/integrations/azure/initial_access_entra_id_rare_app_id_for_principal_auth.toml index 282e1c94053..43c141da69f 100644 --- a/rules/integrations/azure/initial_access_entra_rare_app_id_for_principal_auth.toml +++ b/rules/integrations/azure/initial_access_entra_id_rare_app_id_for_principal_auth.toml @@ -16,10 +16,10 @@ from = "now-9m" index = ["filebeat-*", "logs-azure.signinlogs-*"] language = "kuery" license = "Elastic License v2" -name = "Azure Entra ID Rare App ID for Principal Authentication" +name = "Entra ID User Sign-in with Unusual Client" note = """## Triage and analysis -### Investigating Azure Entra ID Rare App ID for Principal Authentication +### Investigating Entra ID User Sign-in with Unusual Client This rule identifies rare Azure Entra apps IDs requesting authentication on-behalf-of a principal user. An adversary with stolen credentials may specify an Azure-managed app ID to authenticate on-behalf-of a user. This is a rare event and may indicate an attempt to bypass conditional access policies (CAP) and multi-factor authentication (MFA) requirements. The app ID specified may not be commonly used by the user based on their historical sign-in activity. diff --git a/rules/integrations/azure/initial_access_entra_rare_authentication_requirement_for_principal_user.toml b/rules/integrations/azure/initial_access_entra_id_rare_authentication_requirement_for_principal_user.toml similarity index 97% rename from rules/integrations/azure/initial_access_entra_rare_authentication_requirement_for_principal_user.toml rename to rules/integrations/azure/initial_access_entra_id_rare_authentication_requirement_for_principal_user.toml index 923d2bd0f00..1e8d4fbbb9b 100644 --- a/rules/integrations/azure/initial_access_entra_rare_authentication_requirement_for_principal_user.toml +++ b/rules/integrations/azure/initial_access_entra_id_rare_authentication_requirement_for_principal_user.toml @@ -2,7 +2,7 @@ creation_date = "2025/03/10" integration = ["azure"] maturity = "production" -updated_date = "2025/09/26" +updated_date = "2025/10/01" [rule] author = ["Elastic"] @@ -16,10 +16,10 @@ from = "now-9m" index = ["filebeat-*", "logs-azure.signinlogs-*"] language = "kuery" license = "Elastic License v2" -name = "Microsoft Entra ID Rare Authentication Requirement for Principal User" +name = "Entra ID User Sign-in with Unusual Authentication Type" note = """## Triage and analysis -### Investigating Microsoft Entra ID Rare Authentication Requirement for Principal User +### Investigating Entra ID User Sign-in with Unusual Authentication Type Identifies rare instances of authentication requirements for Azure Entra ID principal users. An adversary with stolen credentials may attempt to authenticate with unusual authentication requirements, which is a rare event and may indicate an attempt to bypass conditional access policies (CAP) and multi-factor authentication (MFA) requirements. The authentication requirements specified may not be commonly used by the user based on their historical sign-in activity. diff --git a/rules/integrations/azure/initial_access_azure_active_directory_high_risk_signin_atrisk_or_confirmed.toml b/rules/integrations/azure/initial_access_entra_id_risky_user_or_compromised_sign_in.toml similarity index 96% rename from rules/integrations/azure/initial_access_azure_active_directory_high_risk_signin_atrisk_or_confirmed.toml rename to rules/integrations/azure/initial_access_entra_id_risky_user_or_compromised_sign_in.toml index cc0023d3a6f..2ab9f4a78e7 100644 --- a/rules/integrations/azure/initial_access_azure_active_directory_high_risk_signin_atrisk_or_confirmed.toml +++ b/rules/integrations/azure/initial_access_entra_id_risky_user_or_compromised_sign_in.toml @@ -2,7 +2,7 @@ creation_date = "2021/10/18" integration = ["azure"] maturity = "production" -updated_date = "2025/09/30" +updated_date = "2025/10/01" [rule] author = ["Austin Songer"] @@ -14,10 +14,10 @@ from = "now-9m" index = ["logs-azure.signinlogs-*", "filebeat-*"] language = "kuery" license = "Elastic License v2" -name = "Azure Active Directory High Risk User Sign-in Heuristic" +name = "Entra ID High Risk User Sign-in Heuristic" note = """## Triage and analysis -### Investigating Azure Active Directory High Risk User Sign-in Heuristic +### Investigating Entra ID High Risk User Sign-in Heuristic Microsoft Identity Protection is an Azure AD security tool that detects various types of identity risks and attacks. diff --git a/rules/integrations/azure/initial_access_entra_id_suspicious_oauth_flow_via_auth_broker_to_drs.toml b/rules/integrations/azure/initial_access_entra_id_suspicious_oauth_flow_via_auth_broker_to_drs.toml index 4bade699e93..0f4528e060e 100644 --- a/rules/integrations/azure/initial_access_entra_id_suspicious_oauth_flow_via_auth_broker_to_drs.toml +++ b/rules/integrations/azure/initial_access_entra_id_suspicious_oauth_flow_via_auth_broker_to_drs.toml @@ -2,7 +2,7 @@ creation_date = "2025/04/30" integration = ["azure"] maturity = "production" -updated_date = "2025/09/30" +updated_date = "2025/10/01" [rule] author = ["Elastic"] @@ -25,10 +25,10 @@ from = "now-61m" interval = "60m" language = "esql" license = "Elastic License v2" -name = "Suspicious Microsoft OAuth Flow via Auth Broker to DRS" +name = "Entra ID OAuth Flow by Microsoft Authentication Broker to Device Registration Service (DRS)" note = """## Triage and analysis -### Investigating Suspicious Microsoft OAuth Flow via Auth Broker to DRS +### Investigating Entra ID OAuth Flow by Microsoft Authentication Broker to Device Registration Service (DRS) This rule identifies potential OAuth phishing behavior in Microsoft Entra ID where two OAuth authorization flows are observed in quick succession, sharing the same user principal and session ID but originating from different IP addresses. The client application is the Microsoft Authentication Broker, and the target resource is the Device Registration Service (DRS). This pattern is indicative of adversaries attempting to phish targets for OAuth sessions by tricking users into authenticating through a crafted URL, which then allows the attacker to obtain an authorization code and exchange it for access and refresh tokens. diff --git a/rules/integrations/azure/initial_access_entra_id_unusual_ropc_login_attempt.toml b/rules/integrations/azure/initial_access_entra_id_unusual_ropc_login_attempt.toml index bca0c1f9e54..f637f40485b 100644 --- a/rules/integrations/azure/initial_access_entra_id_unusual_ropc_login_attempt.toml +++ b/rules/integrations/azure/initial_access_entra_id_unusual_ropc_login_attempt.toml @@ -2,7 +2,7 @@ creation_date = "2025/07/02" integration = ["azure"] maturity = "production" -updated_date = "2025/07/02" +updated_date = "2025/10/01" [rule] author = ["Elastic"] @@ -18,10 +18,10 @@ from = "now-9m" index = ["filebeat-*", "logs-azure.signinlogs-*"] language = "kuery" license = "Elastic License v2" -name = "Unusual ROPC Login Attempt by User Principal" +name = "Entra ID OAuth ROPC Grant Login Detected" note = """## Triage and analysis -### Investigating Unusual ROPC Login Attempt by User Principal +### Investigating Entra ID OAuth ROPC Grant Login Detected This rule detects unusual login attempts using the Resource Owner Password Credentials (ROPC) flow in Microsoft Entra ID. ROPC allows applications to obtain tokens by directly providing user credentials, bypassing multi-factor authentication (MFA). This method is less secure and can be exploited by adversaries to gain access to user accounts, especially during enumeration or password spraying. diff --git a/rules/integrations/azure/initial_access_entra_id_user_reported_risk.toml b/rules/integrations/azure/initial_access_entra_id_user_reported_risk.toml index 4492b05a418..f7d453a7c74 100644 --- a/rules/integrations/azure/initial_access_entra_id_user_reported_risk.toml +++ b/rules/integrations/azure/initial_access_entra_id_user_reported_risk.toml @@ -2,7 +2,7 @@ creation_date = "2025/05/21" integration = ["azure"] maturity = "production" -updated_date = "2025/09/26" +updated_date = "2025/10/01" [rule] author = ["Elastic", "Willem D'Haese"] @@ -13,10 +13,10 @@ from = "now-9m" index = ["logs-azure.auditlogs-*"] language = "kuery" license = "Elastic License v2" -name = "Microsoft Entra ID User Reported Suspicious Activity" +name = "Entra ID User Reported Suspicious Activity" note = """## Triage and Analysis -### Investigating Microsoft Entra ID User Reported Suspicious Activity +### Investigating Entra ID User Reported Suspicious Activity This rule detects when a user in Microsoft Entra ID reports suspicious activity associated with their account. This feature is often used to report MFA fatigue or unsolicited push notifications, and is logged during authentication flows involving methods like Microsoft Authenticator. Such events may indicate that an attacker attempted unauthorized access and triggered a push that was denied or flagged by the user. diff --git a/rules/integrations/azure/initial_access_graph_first_occurrence_of_client_request.toml b/rules/integrations/azure/initial_access_graph_first_occurrence_of_client_request.toml index 965b9056187..4ee04d12758 100644 --- a/rules/integrations/azure/initial_access_graph_first_occurrence_of_client_request.toml +++ b/rules/integrations/azure/initial_access_graph_first_occurrence_of_client_request.toml @@ -2,7 +2,7 @@ creation_date = "2025/04/23" integration = ["azure"] maturity = "production" -updated_date = "2025/09/26" +updated_date = "2025/10/01" [rule] author = ["Elastic"] @@ -32,10 +32,10 @@ from = "now-9m" index = ["logs-azure.graphactivitylogs-*"] language = "kuery" license = "Elastic License v2" -name = "Microsoft Graph First Occurrence of Client Request" +name = "Microsoft Graph Request User Impersonation by Unusual Client" note = """## Triage and analysis -### Investigating Microsoft Graph First Occurrence of Client Request +### Investigating Microsoft Graph Request User Impersonation by Unusual Client This rule detects the first observed occurrence of a Microsoft Graph API request by a specific client application ID (`azure.graphactivitylogs.properties.app_id`) in combination with a user principal object ID (`azure.graphactivitylogs.properties.user_principal_object_id`) and tenant ID (`azure.tenant_id`) within the last 14 days. This may indicate unauthorized access following a successful phishing attempt, token theft, or abuse of OAuth workflows. diff --git a/rules/integrations/azure/persistence_azure_automation_account_created.toml b/rules/integrations/azure/persistence_automation_account_created.toml similarity index 100% rename from rules/integrations/azure/persistence_azure_automation_account_created.toml rename to rules/integrations/azure/persistence_automation_account_created.toml diff --git a/rules/integrations/azure/persistence_azure_automation_webhook_created.toml b/rules/integrations/azure/persistence_automation_webhook_created.toml similarity index 100% rename from rules/integrations/azure/persistence_azure_automation_webhook_created.toml rename to rules/integrations/azure/persistence_automation_webhook_created.toml diff --git a/rules/integrations/azure/persistence_azure_application_credential_modification.toml b/rules/integrations/azure/persistence_entra_id_application_credential_modification.toml similarity index 97% rename from rules/integrations/azure/persistence_azure_application_credential_modification.toml rename to rules/integrations/azure/persistence_entra_id_application_credential_modification.toml index ba53cf37167..160f4d0a9a6 100644 --- a/rules/integrations/azure/persistence_azure_application_credential_modification.toml +++ b/rules/integrations/azure/persistence_entra_id_application_credential_modification.toml @@ -2,7 +2,7 @@ creation_date = "2020/12/14" integration = ["azure"] maturity = "production" -updated_date = "2025/09/30" +updated_date = "2025/10/01" [rule] author = ["Elastic"] @@ -24,13 +24,13 @@ from = "now-9m" index = ["logs-azure.auditlogs-*", "filebeat-*"] language = "kuery" license = "Elastic License v2" -name = "Azure Application Credential Modification" +name = "Entra ID Application Credential Modified" 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 Application Credential Modification +### Investigating Entra ID Application Credential Modified Azure applications use credentials like certificates or secret strings for identity verification during token requests. Adversaries may exploit this by adding unauthorized credentials, enabling persistent access or evading defenses. The detection rule monitors audit logs for successful updates to application credentials, flagging potential misuse by identifying unauthorized credential modifications. diff --git a/rules/integrations/azure/persistence_entra_conditional_access_policy_modified.toml b/rules/integrations/azure/persistence_entra_id_conditional_access_policy_modified.toml similarity index 98% rename from rules/integrations/azure/persistence_entra_conditional_access_policy_modified.toml rename to rules/integrations/azure/persistence_entra_id_conditional_access_policy_modified.toml index a5b45d0fffa..ad4f19af6f7 100644 --- a/rules/integrations/azure/persistence_entra_conditional_access_policy_modified.toml +++ b/rules/integrations/azure/persistence_entra_id_conditional_access_policy_modified.toml @@ -2,7 +2,7 @@ creation_date = "2020/09/01" integration = ["azure"] maturity = "production" -updated_date = "2025/09/26" +updated_date = "2025/10/01" [rule] author = ["Elastic"] @@ -13,7 +13,7 @@ from = "now-9m" index = ["filebeat-*", "logs-azure.auditlogs-*"] language = "kuery" license = "Elastic License v2" -name = "Microsoft Entra ID Conditional Access Policy (CAP) Modified" +name = "Entra ID Conditional Access Policy (CAP) Modified" note = """## Triage and analysis ## Investigation Guide: Microsoft Entra ID Conditional Access Policy (CAP) Modified diff --git a/rules/integrations/azure/persistence_azure_global_administrator_role_assigned.toml b/rules/integrations/azure/persistence_entra_id_global_administrator_role_assigned.toml similarity index 100% rename from rules/integrations/azure/persistence_azure_global_administrator_role_assigned.toml rename to rules/integrations/azure/persistence_entra_id_global_administrator_role_assigned.toml diff --git a/rules/integrations/azure/persistence_entra_id_oidc_discovery_url_change.toml b/rules/integrations/azure/persistence_entra_id_oidc_discovery_url_change.toml index b2d9420100a..79afca62642 100644 --- a/rules/integrations/azure/persistence_entra_id_oidc_discovery_url_change.toml +++ b/rules/integrations/azure/persistence_entra_id_oidc_discovery_url_change.toml @@ -2,7 +2,7 @@ creation_date = "2025/07/14" integration = ["azure"] maturity = "production" -updated_date = "2025/09/26" +updated_date = "2025/10/01" [rule] author = ["Elastic"] @@ -15,10 +15,10 @@ from = "now-9m" interval = "8m" language = "esql" license = "Elastic License v2" -name = "OIDC Discovery URL Changed in Entra ID" +name = "Entra ID OIDC Discovery URL Modified" note = """## Triage and analysis -### Investigating OIDC Discovery URL Changed in Entra ID +### Investigating Entra ID OIDC Discovery URL Modified This rule detects when the OIDC `discoveryUrl` is changed within the Entra ID Authentication Methods policy. Adversaries may leverage this to federate Entra ID with a rogue Identity Provider (IdP) under their control, allowing them to authenticate users with attacker-owned credentials and bypass MFA. This misconfiguration allows an attacker to impersonate valid users by issuing tokens via a third-party OIDC IdP while still passing validation in Entra ID. This technique has been publicly demonstrated and has critical implications for trust in federated identity. diff --git a/rules/integrations/azure/persistence_azure_pim_user_added_global_admin.toml b/rules/integrations/azure/persistence_entra_id_pim_user_added_global_admin.toml similarity index 97% rename from rules/integrations/azure/persistence_azure_pim_user_added_global_admin.toml rename to rules/integrations/azure/persistence_entra_id_pim_user_added_global_admin.toml index 44795b883b1..1961a6700c5 100644 --- a/rules/integrations/azure/persistence_azure_pim_user_added_global_admin.toml +++ b/rules/integrations/azure/persistence_entra_id_pim_user_added_global_admin.toml @@ -2,7 +2,7 @@ creation_date = "2020/09/24" integration = ["azure"] maturity = "production" -updated_date = "2025/09/30" +updated_date = "2025/10/01" [rule] author = ["Elastic"] @@ -23,13 +23,13 @@ false_positives = [ index = ["logs-azure.auditlogs-*", "filebeat-*"] language = "kuery" license = "Elastic License v2" -name = "Azure Global Administrator Role Addition to PIM User" +name = "Entra ID Global Administrator Role Assigned (PIM User)" 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 Global Administrator Role Addition to PIM User +### Investigating Entra ID Global Administrator Role Assigned (PIM User) Azure AD's Global Administrator role grants extensive access, allowing users to modify any administrative setting. Privileged Identity Management (PIM) helps manage and monitor such access. Adversaries may exploit this by adding themselves or others to this role, gaining persistent control. The detection rule identifies suspicious role additions by monitoring specific audit logs, focusing on successful role assignments to PIM users, thus helping to flag potential unauthorized access attempts. diff --git a/rules/integrations/azure/persistence_azure_privileged_identity_management_role_modified.toml b/rules/integrations/azure/persistence_entra_id_privileged_identity_management_role_modified.toml similarity index 96% rename from rules/integrations/azure/persistence_azure_privileged_identity_management_role_modified.toml rename to rules/integrations/azure/persistence_entra_id_privileged_identity_management_role_modified.toml index 92c1be58ff5..fba40329fb4 100644 --- a/rules/integrations/azure/persistence_azure_privileged_identity_management_role_modified.toml +++ b/rules/integrations/azure/persistence_entra_id_privileged_identity_management_role_modified.toml @@ -2,7 +2,7 @@ creation_date = "2020/09/01" integration = ["azure"] maturity = "production" -updated_date = "2025/09/30" +updated_date = "2025/10/01" [rule] author = ["Elastic"] @@ -16,10 +16,10 @@ from = "now-9m" index = ["logs-azure.auditlogs-*", "filebeat-*"] language = "kuery" license = "Elastic License v2" -name = "Azure Privilege Identity Management Role Modified" +name = "Entra ID Privileged Identity Management (PIM) Role Modified" note = """## Triage and analysis -### Investigating Azure Privilege Identity Management Role Modified +### Investigating Entra ID Privileged Identity Management (PIM) Role Modified Azure Active Directory (AD) Privileged Identity Management (PIM) is a service that enables you to manage, control, and monitor access to important resources in an organization. PIM can be used to manage the built-in Azure resource roles such as Global Administrator and Application Administrator. diff --git a/rules/integrations/azure/persistence_entra_id_rt_to_prt_transition_from_user_device.toml b/rules/integrations/azure/persistence_entra_id_rt_to_prt_transition_from_user_device.toml index 1899b1dd2c9..1b5e6b004e6 100644 --- a/rules/integrations/azure/persistence_entra_id_rt_to_prt_transition_from_user_device.toml +++ b/rules/integrations/azure/persistence_entra_id_rt_to_prt_transition_from_user_device.toml @@ -2,7 +2,7 @@ creation_date = "2025/06/24" integration = ["azure"] maturity = "production" -updated_date = "2025/09/26" +updated_date = "2025/10/01" [rule] author = ["Elastic"] @@ -18,10 +18,10 @@ index = ["filebeat-*", "logs-azure.signinlogs-*"] interval = "30m" language = "eql" license = "Elastic License v2" -name = "Entra ID RT to PRT Transition from Same User and Device" +name = "Entra ID OAuth Primary Refresh Token (PRT) Issuance via Refresh Token (RT) Detected" note = """## Triage and analysis -### Investigating Entra ID RT to PRT Transition from Same User and Device +### Investigating Entra ID OAuth Primary Refresh Token (PRT) Issuance via Refresh Token (RT) Detected This rule identifies a sequence where a Microsoft Entra ID user signs in using a refresh token issued to the Microsoft Authentication Broker (MAB), followed by a sign-in using a Primary Refresh Token (PRT) from the same device. This behavior is uncommon for normal user activity and strongly suggests adversarial behavior, particularly when paired with OAuth phishing and device registration tools like ROADtx. The use of PRT shortly after a refresh token sign-in typically indicates the attacker has obtained device trust and is now using the PRT to impersonate a fully compliant user+device pair. diff --git a/rules/integrations/azure/persistence_entra_service_principal_created.toml b/rules/integrations/azure/persistence_entra_id_service_principal_created.toml similarity index 97% rename from rules/integrations/azure/persistence_entra_service_principal_created.toml rename to rules/integrations/azure/persistence_entra_id_service_principal_created.toml index 32bb180ec3a..ae0b59e7d6e 100644 --- a/rules/integrations/azure/persistence_entra_service_principal_created.toml +++ b/rules/integrations/azure/persistence_entra_id_service_principal_created.toml @@ -2,7 +2,7 @@ creation_date = "2020/12/14" integration = ["azure"] maturity = "production" -updated_date = "2025/05/05" +updated_date = "2025/10/01" [rule] author = ["Elastic"] @@ -23,10 +23,10 @@ from = "now-9m" index = ["filebeat-*", "logs-azure.auditlogs-*"] language = "kuery" license = "Elastic License v2" -name = "Microsoft Entra ID Service Principal Created" +name = "Entra ID Service Principal Created" note = """## Triage and analysis -### Investigating Microsoft Entra ID Service Principal Created +### Investigating Entra ID Service Principal Created Service Principals are identities used by applications, services, and automation tools to access specific resources. They grant specific access based on the assigned API permissions. Most organizations that work a lot with Azure AD make use of service principals. Whenever an application is registered, it automatically creates an application object and a service principal in an Azure AD tenant. diff --git a/rules/integrations/azure/persistence_azure_service_principal_credentials_added.toml b/rules/integrations/azure/persistence_entra_id_service_principal_credentials_added.toml similarity index 96% rename from rules/integrations/azure/persistence_azure_service_principal_credentials_added.toml rename to rules/integrations/azure/persistence_entra_id_service_principal_credentials_added.toml index c2933e331c2..ebeb1c91dee 100644 --- a/rules/integrations/azure/persistence_azure_service_principal_credentials_added.toml +++ b/rules/integrations/azure/persistence_entra_id_service_principal_credentials_added.toml @@ -2,7 +2,7 @@ creation_date = "2021/05/05" integration = ["azure"] maturity = "production" -updated_date = "2025/05/27" +updated_date = "2025/10/01" [rule] author = ["Elastic", "Austin Songer"] @@ -24,10 +24,10 @@ from = "now-9m" index = ["filebeat-*", "logs-azure.auditlogs-*"] language = "kuery" license = "Elastic License v2" -name = "Microsoft Entra ID Service Principal Credentials Added by Rare User" +name = "Entra ID Service Principal Credentials Created by Unusual User" note = """## Triage and analysis -### Investigating Microsoft Entra ID Service Principal Credentials Added by Rare User +### Investigating Entra ID Service Principal Credentials Created by Unusual User This rule identifies the addition of new credentials (client secrets or certificates) to a Microsoft Entra ID (formerly Azure AD) service principal by a user who has not previously performed this operation in the last 10 days. Adversaries who obtain temporary or persistent access to a user account may add rogue credentials to service principals in order to maintain unauthorized access to cloud resources. diff --git a/rules/integrations/azure/persistence_entra_id_suspicious_adrs_token_request.toml b/rules/integrations/azure/persistence_entra_id_suspicious_adrs_token_request.toml index ae192a5b237..50b902060c4 100644 --- a/rules/integrations/azure/persistence_entra_id_suspicious_adrs_token_request.toml +++ b/rules/integrations/azure/persistence_entra_id_suspicious_adrs_token_request.toml @@ -2,7 +2,7 @@ creation_date = "2025/06/13" integration = ["azure"] maturity = "production" -updated_date = "2025/06/13" +updated_date = "2025/10/01" [rule] author = ["Elastic"] @@ -18,10 +18,10 @@ from = "now-9m" index = ["filebeat-*", "logs-azure.signinlogs-*"] language = "kuery" license = "Elastic License v2" -name = "Suspicious ADRS Token Request by Microsoft Auth Broker" +name = "Entra ID ADRS Token Request by Microsoft Authentication Broker" note = """## Triage and analysis -### Investigating Suspicious ADRS Token Request by Microsoft Auth Broker +### Investigating Entra ID ADRS Token Request by Microsoft Authentication Broker Detects suspicious OAuth 2.0 token requests where the Microsoft Authentication Broker (29d9ed98-a469-4536-ade2-f981bc1d605e) requests access to the Device Registration Service (01cb2876-7ebd-4aa4-9cc9-d28bd4d359a9) on behalf of a user principal. The presence of the adrs_access scope in the authentication processing details suggests an attempt to access ADRS, which is atypical for standard user sign-ins. This behavior may reflect an effort to abuse device registration for unauthorized persistence, such as acquiring a Primary Refresh Token (PRT) or establishing a trusted session. diff --git a/rules/integrations/azure/persistence_entra_id_suspicious_cloud_device_registration.toml b/rules/integrations/azure/persistence_entra_id_suspicious_cloud_device_registration.toml index d5e9e59a5be..8936dabe90a 100644 --- a/rules/integrations/azure/persistence_entra_id_suspicious_cloud_device_registration.toml +++ b/rules/integrations/azure/persistence_entra_id_suspicious_cloud_device_registration.toml @@ -2,7 +2,7 @@ creation_date = "2025/06/13" integration = ["azure"] maturity = "production" -updated_date = "2025/06/13" +updated_date = "2025/10/01" [rule] author = ["Elastic"] @@ -18,10 +18,10 @@ from = "now-9m" index = ["filebeat-*", "logs-azure.auditlogs-*"] language = "eql" license = "Elastic License v2" -name = "Microsoft Entra ID Suspicious Cloud Device Registration" +name = "Entra ID Device Registration Detected (ROADtools)" note = """## Triage and analysis -### Investigating Microsoft Entra ID Suspicious Cloud Device Registration +### Investigating Entra ID Device Registration Detected (ROADtools) This rule detects a sequence of Microsoft Entra ID audit events consistent with cloud device registration abuse via ROADtools or similar automation. The activity includes three correlated events: diff --git a/rules/integrations/azure/persistence_user_added_as_owner_for_azure_application.toml b/rules/integrations/azure/persistence_entra_id_user_added_as_owner_for_azure_application.toml similarity index 97% rename from rules/integrations/azure/persistence_user_added_as_owner_for_azure_application.toml rename to rules/integrations/azure/persistence_entra_id_user_added_as_owner_for_azure_application.toml index 06586396bad..8dcc173462e 100644 --- a/rules/integrations/azure/persistence_user_added_as_owner_for_azure_application.toml +++ b/rules/integrations/azure/persistence_entra_id_user_added_as_owner_for_azure_application.toml @@ -2,7 +2,7 @@ creation_date = "2020/08/20" integration = ["azure"] maturity = "production" -updated_date = "2025/09/30" +updated_date = "2025/10/01" [rule] author = ["Elastic"] @@ -15,13 +15,13 @@ from = "now-9m" index = ["logs-azure.auditlogs-*", "filebeat-*"] language = "kuery" license = "Elastic License v2" -name = "User Added as Owner for Azure Application" +name = "Entra ID User Added as Registered Application Owner" 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 User Added as Owner for Azure Application +### Investigating Entra ID User Added as Registered Application Owner Azure applications often require specific permissions for functionality, managed by assigning user roles. An adversary might exploit this by adding themselves or a compromised account as an owner, gaining elevated privileges to alter configurations or access sensitive data. The detection rule monitors audit logs for successful operations where a user is added as an application owner, flagging potential unauthorized privilege escalations. diff --git a/rules/integrations/azure/persistence_user_added_as_owner_for_azure_service_principal.toml b/rules/integrations/azure/persistence_entra_id_user_added_as_owner_for_azure_service_principal.toml similarity index 97% rename from rules/integrations/azure/persistence_user_added_as_owner_for_azure_service_principal.toml rename to rules/integrations/azure/persistence_entra_id_user_added_as_owner_for_azure_service_principal.toml index f70a5d3b6b7..2d9e1d06530 100644 --- a/rules/integrations/azure/persistence_user_added_as_owner_for_azure_service_principal.toml +++ b/rules/integrations/azure/persistence_entra_id_user_added_as_owner_for_azure_service_principal.toml @@ -2,7 +2,7 @@ creation_date = "2020/08/20" integration = ["azure"] maturity = "production" -updated_date = "2025/09/30" +updated_date = "2025/10/01" [rule] author = ["Elastic"] @@ -17,13 +17,13 @@ from = "now-9m" index = ["logs-azure.auditlogs-*", "filebeat-*"] language = "kuery" license = "Elastic License v2" -name = "User Added as Owner for Azure Service Principal" +name = "Entra ID User Added as Service Principal Owner" 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 User Added as Owner for Azure Service Principal +### Investigating Entra ID User Added as Service Principal Owner Azure service principals are crucial for managing application permissions within a tenant, defining access and capabilities. Adversaries may exploit this by adding themselves as owners, gaining control over application permissions and access. The detection rule monitors audit logs for successful owner additions, flagging potential unauthorized changes to maintain security integrity. diff --git a/rules/integrations/azure/persistence_entra_id_user_signed_in_from_unusual_device.toml b/rules/integrations/azure/persistence_entra_id_user_signed_in_from_unusual_device.toml index 5c790fe547b..ed68f77afcd 100644 --- a/rules/integrations/azure/persistence_entra_id_user_signed_in_from_unusual_device.toml +++ b/rules/integrations/azure/persistence_entra_id_user_signed_in_from_unusual_device.toml @@ -2,7 +2,7 @@ creation_date = "2025/06/16" integration = ["azure"] maturity = "production" -updated_date = "2025/06/16" +updated_date = "2025/10/01" [rule] author = ["Elastic"] @@ -16,10 +16,10 @@ from = "now-9m" index = ["filebeat-*", "logs-azure.signinlogs-*"] language = "kuery" license = "Elastic License v2" -name = "Entra ID User Signed In from Unusual Device" +name = "Entra ID User Sign-in with Unusual Registered Device" note = """## Triage and analysis -### Investigating Entra ID User Signed In from Unusual Device +### Investigating Entra ID User Sign-in with Unusual Registered Device This rule detects when a Microsoft Entra ID user signs in from a device that is not typically used by the user, which may indicate potential compromise or unauthorized access attempts. This rule detects unusual sign-in activity by comparing the device used for the sign-in against the user's typical device usage patterns. Adversaries may create and register a new device to obtain a Primary Refresh Token (PRT) and maintain persistent access. diff --git a/rules/integrations/azure/persistence_update_event_hub_auth_rule.toml b/rules/integrations/azure/persistence_event_hub_created_or_updated.toml similarity index 100% rename from rules/integrations/azure/persistence_update_event_hub_auth_rule.toml rename to rules/integrations/azure/persistence_event_hub_created_or_updated.toml diff --git a/rules/integrations/azure/persistence_graph_eam_addition_or_modification.toml b/rules/integrations/azure/persistence_graph_eam_addition_or_modification.toml index 59f62c55e3f..308d5093d50 100644 --- a/rules/integrations/azure/persistence_graph_eam_addition_or_modification.toml +++ b/rules/integrations/azure/persistence_graph_eam_addition_or_modification.toml @@ -2,7 +2,7 @@ creation_date = "2025/07/14" integration = ["azure"] maturity = "production" -updated_date = "2025/07/14" +updated_date = "2025/10/01" [rule] author = ["Elastic"] @@ -15,10 +15,10 @@ from = "now-9m" index = ["filebeat-*", "logs-azure.graphactivitylogs-*"] language = "kuery" license = "Elastic License v2" -name = "External Authentication Method Addition or Modification in Entra ID" +name = "Entra ID External Authentication Methods (EAM) Modified" note = """## Triage and analysis -### Investigating External Authentication Method Addition or Modification in Entra ID +### Investigating Entra ID External Authentication Methods (EAM) Modified This rule detects suspicious modifications to external authentication methods (EAMs) in Microsoft Entra ID via Microsoft Graph API. Adversaries may abuse this capability to bypass multi-factor authentication (MFA), enabling persistence or unauthorized access through bring-your-own identity provider (BYOIDP) methods. diff --git a/rules/integrations/azure/persistence_identity_protect_alert_followed_by_device_reg.toml b/rules/integrations/azure/persistence_identity_protect_alert_followed_by_device_reg.toml index c182f9aecb4..5d7e4704e5e 100644 --- a/rules/integrations/azure/persistence_identity_protect_alert_followed_by_device_reg.toml +++ b/rules/integrations/azure/persistence_identity_protect_alert_followed_by_device_reg.toml @@ -2,7 +2,7 @@ creation_date = "2025/04/30" integration = ["azure"] maturity = "production" -updated_date = "2025/09/30" +updated_date = "2025/10/01" [rule] author = ["Elastic"] @@ -13,10 +13,10 @@ from = "now-9m" index = ["logs-azure.identity_protection-*", "logs-azure.auditlogs-*"] language = "eql" license = "Elastic License v2" -name = "Microsoft Entra ID Protection Alert and Device Registration" +name = "Entra ID Protection User Alert and Device Registration" note = """## Triage and analysis -### Investigating Microsoft Entra ID Protection Alert and Device Registration +### Investigating Entra ID Protection User Alert and Device Registration #### Possible investigation steps diff --git a/rules/integrations/azure/privilege_escalation_entra_id_elevate_to_user_administrator_access.toml b/rules/integrations/azure/privilege_escalation_entra_id_elevate_to_user_administrator_access.toml index 90660c36cb0..85fa5adf2fc 100644 --- a/rules/integrations/azure/privilege_escalation_entra_id_elevate_to_user_administrator_access.toml +++ b/rules/integrations/azure/privilege_escalation_entra_id_elevate_to_user_administrator_access.toml @@ -2,7 +2,7 @@ creation_date = "2025/05/22" integration = ["azure"] maturity = "production" -updated_date = "2025/09/15" +updated_date = "2025/10/01" [rule] author = ["Elastic", "Austin Songer"] @@ -18,10 +18,10 @@ from = "now-9m" index = ["filebeat-*", "logs-azure.auditlogs-*"] language = "kuery" license = "Elastic License v2" -name = "Microsoft Entra ID Elevated Access to User Access Administrator" +name = "Entra ID Elevated Access to User Access Administrator" note = """## Triage and Analysis -### Investigating Microsoft Entra ID Elevated Access to User Access Administrator +### Investigating Entra ID Elevated Access to User Access Administrator This rule identifies when a user elevates their permissions to the "User Access Administrator" role in Azure RBAC. This role allows full control over access management for Azure resources and can be abused by attackers for lateral movement, persistence, or privilege escalation. Since this is a New Terms rule, the alert will only trigger if the user has not performed this elevation in the past 14 days, helping reduce alert fatigue. diff --git a/rules/integrations/azure/privilege_escalation_azure_kubernetes_rolebinding_created.toml b/rules/integrations/azure/privilege_escalation_kubernetes_aks_rolebinding_created.toml similarity index 97% rename from rules/integrations/azure/privilege_escalation_azure_kubernetes_rolebinding_created.toml rename to rules/integrations/azure/privilege_escalation_kubernetes_aks_rolebinding_created.toml index 408ba4880c4..cf42f219626 100644 --- a/rules/integrations/azure/privilege_escalation_azure_kubernetes_rolebinding_created.toml +++ b/rules/integrations/azure/privilege_escalation_kubernetes_aks_rolebinding_created.toml @@ -2,7 +2,7 @@ creation_date = "2021/10/18" integration = ["azure"] maturity = "production" -updated_date = "2025/09/30" +updated_date = "2025/10/01" [rule] author = ["Austin Songer"] @@ -16,13 +16,13 @@ from = "now-9m" index = ["logs-azure.activitylogs-*", "filebeat-*"] language = "kuery" license = "Elastic License v2" -name = "Azure Kubernetes Rolebindings Created" +name = "Azure Kubernetes Services (AKS) Kubernetes Rolebindings Created" 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 Kubernetes Rolebindings Created +### Investigating Azure Kubernetes Services (AKS) Kubernetes Rolebindings Created Azure Kubernetes role bindings are crucial for managing access control within Kubernetes clusters, allowing specific permissions to be assigned to users, groups, or service accounts. Adversaries with the ability to create these bindings can escalate privileges by assigning themselves or others high-level roles, such as cluster-admin. The detection rule monitors Azure activity logs for successful creation events of role or cluster role bindings, signaling potential unauthorized privilege escalation attempts. ### Possible investigation steps diff --git a/rules/integrations/o365/collection_microsoft_365_excessive_mail_items_accessed.toml b/rules/integrations/o365/collection_exchange_excessive_mail_items_accessed.toml similarity index 97% rename from rules/integrations/o365/collection_microsoft_365_excessive_mail_items_accessed.toml rename to rules/integrations/o365/collection_exchange_excessive_mail_items_accessed.toml index 6ee48682bc2..6efdaad610d 100644 --- a/rules/integrations/o365/collection_microsoft_365_excessive_mail_items_accessed.toml +++ b/rules/integrations/o365/collection_exchange_excessive_mail_items_accessed.toml @@ -2,7 +2,7 @@ creation_date = "2025/06/17" integration = ["o365"] maturity = "production" -updated_date = "2025/06/17" +updated_date = "2025/10/01" [rule] author = ["Elastic"] @@ -24,10 +24,10 @@ from = "now-9m" index = ["filebeat-*", "logs-o365.audit-*"] language = "kuery" license = "Elastic License v2" -name = "Excessive Microsoft 365 Mailbox Items Accessed" +name = "M365 Exchange Mailbox Items Accessed Excessively" note = """## Triage and analysis -### Investigating Excessive Microsoft 365 Mailbox Items Accessed +### Investigating M365 Exchange Mailbox Items Accessed Excessively Identifies an excessive number of Microsoft 365 mailbox items accessed by a user either via aggregated counts or throttling. Microsoft audits mailbox access via the MailItemsAccessed event, which is triggered when a user accesses mailbox items. If more than 1000 mailbox items are accessed within a 24-hour period, it is then throttled. Excessive mailbox access may indicate an adversary attempting to exfiltrate sensitive information or perform reconnaissance on a target's mailbox. This rule detects both the throttled and unthrottled events with a high threshold. diff --git a/rules/integrations/o365/collection_microsoft_365_mailbox_access_by_unusual_client_app_id.toml b/rules/integrations/o365/collection_exchange_mailbox_access_by_unusual_client_app_id.toml similarity index 98% rename from rules/integrations/o365/collection_microsoft_365_mailbox_access_by_unusual_client_app_id.toml rename to rules/integrations/o365/collection_exchange_mailbox_access_by_unusual_client_app_id.toml index 0a3f55de286..1742dfea782 100644 --- a/rules/integrations/o365/collection_microsoft_365_mailbox_access_by_unusual_client_app_id.toml +++ b/rules/integrations/o365/collection_exchange_mailbox_access_by_unusual_client_app_id.toml @@ -2,7 +2,7 @@ creation_date = "2023/07/18" integration = ["o365"] maturity = "production" -updated_date = "2025/06/16" +updated_date = "2025/10/01" [rule] author = ["Elastic"] @@ -28,10 +28,10 @@ from = "now-9m" index = ["filebeat-*", "logs-o365.audit-*"] language = "kuery" license = "Elastic License v2" -name = "Suspicious Microsoft 365 Mail Access by Unusual ClientAppId" +name = "M365 Exchange Mailbox Accessed by Unusual Client" note = """## Triage and Analysis -### Investigating Suspicious Microsoft 365 Mail Access by Unusual ClientAppId +### Investigating M365 Exchange Mailbox Accessed by Unusual Client This rule detects when a user accesses their mailbox using a client application that is not typically used by the user, which may indicate potential compromise or unauthorized access attempts. Adversaries may use custom or third-party applications to access mailboxes, bypassing standard security controls. First-party Microsoft applications are also abused after OAuth tokens are compromised, allowing adversaries to access mailboxes without raising suspicion. diff --git a/rules/integrations/o365/collection_microsoft_365_new_inbox_rule.toml b/rules/integrations/o365/collection_exchange_new_inbox_rule.toml similarity index 97% rename from rules/integrations/o365/collection_microsoft_365_new_inbox_rule.toml rename to rules/integrations/o365/collection_exchange_new_inbox_rule.toml index d2f9a375c79..fdbc69ececb 100644 --- a/rules/integrations/o365/collection_microsoft_365_new_inbox_rule.toml +++ b/rules/integrations/o365/collection_exchange_new_inbox_rule.toml @@ -2,7 +2,7 @@ creation_date = "2021/03/29" integration = ["o365"] maturity = "production" -updated_date = "2025/09/26" +updated_date = "2025/10/01" [rule] author = ["Elastic", "Gary Blackwell", "Austin Songer"] @@ -22,13 +22,13 @@ from = "now-9m" index = ["logs-o365.audit-*", "filebeat-*"] language = "kuery" license = "Elastic License v2" -name = "Microsoft 365 Inbox Forwarding Rule Created" +name = "M365 Exchange Inbox Forwarding Rule Created" 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 Microsoft 365 Inbox Forwarding Rule Created +### Investigating M365 Exchange Inbox Forwarding Rule Created Microsoft 365 allows users to create inbox rules to automate email management, such as forwarding messages to another address. While useful, attackers can exploit these rules to secretly redirect emails, facilitating data exfiltration. The detection rule monitors for the creation of such forwarding rules, focusing on successful events that specify forwarding parameters, thus identifying potential unauthorized email redirection activities. diff --git a/rules/integrations/o365/credential_access_antra_id_device_reg_via_oauth_redirection.toml b/rules/integrations/o365/credential_access_entra_id_device_reg_via_oauth_redirection.toml similarity index 96% rename from rules/integrations/o365/credential_access_antra_id_device_reg_via_oauth_redirection.toml rename to rules/integrations/o365/credential_access_entra_id_device_reg_via_oauth_redirection.toml index d8ea71f9ce1..27d17d389a5 100644 --- a/rules/integrations/o365/credential_access_antra_id_device_reg_via_oauth_redirection.toml +++ b/rules/integrations/o365/credential_access_entra_id_device_reg_via_oauth_redirection.toml @@ -2,7 +2,7 @@ creation_date = "2025/04/30" integration = ["o365"] maturity = "production" -updated_date = "2025/09/26" +updated_date = "2025/10/01" [rule] author = ["Elastic"] @@ -18,10 +18,10 @@ index = ["filebeat-*", "logs-o365.audit-*"] interval = "15m" language = "eql" license = "Elastic License v2" -name = "Microsoft 365 OAuth Redirect to Device Registration for User Principal" +name = "M365 Identity OAuth Flow by User Sign-in to Device Registration" note = """## Triage and analysis -### Investigating Microsoft 365 OAuth Redirect to Device Registration for User Principal +### Investigating M365 Identity OAuth Flow by User Sign-in to Device Registration ### Possible investigation steps - Review the two UserLoggedIn logs to confirm that they come from different source.ip values and are associated to the same account. diff --git a/rules/integrations/o365/credential_access_microsoft_365_potential_user_account_brute_force.toml b/rules/integrations/o365/credential_access_entra_id_potential_user_account_brute_force.toml similarity index 98% rename from rules/integrations/o365/credential_access_microsoft_365_potential_user_account_brute_force.toml rename to rules/integrations/o365/credential_access_entra_id_potential_user_account_brute_force.toml index 20413cd6ea4..a01a5ba86de 100644 --- a/rules/integrations/o365/credential_access_microsoft_365_potential_user_account_brute_force.toml +++ b/rules/integrations/o365/credential_access_entra_id_potential_user_account_brute_force.toml @@ -2,7 +2,7 @@ creation_date = "2020/11/30" integration = ["o365"] maturity = "production" -updated_date = "2025/07/16" +updated_date = "2025/10/01" [rule] author = ["Elastic", "Willem D'Haese", "Austin Songer"] @@ -21,10 +21,10 @@ from = "now-60m" interval = "10m" language = "esql" license = "Elastic License v2" -name = "Potential Microsoft 365 User Account Brute Force" +name = "M365 Identity User Brute Force Attempt" note = """## Triage and Analysis -### Investigating Potential Microsoft 365 User Account Brute Force +### Investigating M365 Identity User Brute Force Attempt Identifies brute-force authentication activity targeting Microsoft 365 user accounts using failed sign-in patterns that match password spraying, credential stuffing, or password guessing behavior. Adversaries may attempt brute-force authentication with credentials obtained from previous breaches, leaks, marketplaces or guessable passwords. diff --git a/rules/integrations/o365/credential_access_user_excessive_sso_logon_errors.toml b/rules/integrations/o365/credential_access_entra_id_user_excessive_sso_logon_errors.toml similarity index 97% rename from rules/integrations/o365/credential_access_user_excessive_sso_logon_errors.toml rename to rules/integrations/o365/credential_access_entra_id_user_excessive_sso_logon_errors.toml index f511dc9e4a7..ac150d1c2e9 100644 --- a/rules/integrations/o365/credential_access_user_excessive_sso_logon_errors.toml +++ b/rules/integrations/o365/credential_access_entra_id_user_excessive_sso_logon_errors.toml @@ -2,7 +2,7 @@ creation_date = "2021/05/17" integration = ["o365"] maturity = "production" -updated_date = "2025/09/26" +updated_date = "2025/10/01" [rule] author = ["Elastic", "Austin Songer"] @@ -20,13 +20,13 @@ from = "now-9m" index = ["logs-o365.audit-*", "filebeat-*"] language = "kuery" license = "Elastic License v2" -name = "O365 Excessive Single Sign-On Logon Errors" +name = "M365 Identity Excessive SSO Login Errors Reported" 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 O365 Excessive Single Sign-On Logon Errors +### Investigating M365 Identity Excessive SSO Login Errors Reported Single Sign-On (SSO) in O365 streamlines user access by allowing one set of credentials for multiple applications. However, adversaries may exploit this by attempting brute force attacks to gain unauthorized access. The detection rule monitors for frequent SSO logon errors, signaling potential abuse, and helps identify compromised accounts by flagging unusual authentication patterns. diff --git a/rules/integrations/o365/credential_access_microsoft_365_excessive_account_lockouts.toml b/rules/integrations/o365/credential_access_identity_user_account_lockouts.toml similarity index 97% rename from rules/integrations/o365/credential_access_microsoft_365_excessive_account_lockouts.toml rename to rules/integrations/o365/credential_access_identity_user_account_lockouts.toml index c7e0fa5da6a..eeec75b4841 100644 --- a/rules/integrations/o365/credential_access_microsoft_365_excessive_account_lockouts.toml +++ b/rules/integrations/o365/credential_access_identity_user_account_lockouts.toml @@ -2,7 +2,7 @@ creation_date = "2025/05/10" integration = ["o365"] maturity = "production" -updated_date = "2025/09/30" +updated_date = "2025/10/01" [rule] author = ["Elastic"] @@ -14,10 +14,10 @@ from = "now-9m" interval = "8m" language = "esql" license = "Elastic License v2" -name = "Multiple Microsoft 365 User Account Lockouts in Short Time Window" +name = "M365 Identity User Account Lockouts" note = """## Triage and Analysis -### Investigating Multiple Microsoft 365 User Account Lockouts in Short Time Window +### Investigating M365 Identity User Account Lockouts Detects a burst of Microsoft 365 user account lockouts within a short 5-minute window. A high number of IdsLocked login errors across multiple user accounts may indicate brute-force attempts for the same users resulting in lockouts. diff --git a/rules/integrations/o365/defense_evasion_microsoft_365_susp_oauth2_authorization.toml b/rules/integrations/o365/defense_evasion_entra_id_susp_oauth2_authorization.toml similarity index 97% rename from rules/integrations/o365/defense_evasion_microsoft_365_susp_oauth2_authorization.toml rename to rules/integrations/o365/defense_evasion_entra_id_susp_oauth2_authorization.toml index 29c7c6a970e..af383826668 100644 --- a/rules/integrations/o365/defense_evasion_microsoft_365_susp_oauth2_authorization.toml +++ b/rules/integrations/o365/defense_evasion_entra_id_susp_oauth2_authorization.toml @@ -2,7 +2,7 @@ creation_date = "2025/05/01" integration = ["o365"] maturity = "production" -updated_date = "2025/09/26" +updated_date = "2025/10/01" [rule] author = ["Elastic"] @@ -15,10 +15,10 @@ from = "now-60m" interval = "59m" language = "esql" license = "Elastic License v2" -name = "Suspicious Microsoft 365 UserLoggedIn via OAuth Code" +name = "M365 Identity OAuth Flow by Rare Client to Microsoft Graph" note = """## Triage and analysis -### Investigating Suspicious Microsoft 365 UserLoggedIn via OAuth Code +### Investigating M365 Identity OAuth Flow by Rare Client to Microsoft Graph ### Possible Investigation Steps: diff --git a/rules/integrations/o365/defense_evasion_microsoft_365_exchange_anti_phish_policy_deletion.toml b/rules/integrations/o365/defense_evasion_exchange_anti_phish_policy_deletion.toml similarity index 97% rename from rules/integrations/o365/defense_evasion_microsoft_365_exchange_anti_phish_policy_deletion.toml rename to rules/integrations/o365/defense_evasion_exchange_anti_phish_policy_deletion.toml index acb20c1c198..24d64c60f9f 100644 --- a/rules/integrations/o365/defense_evasion_microsoft_365_exchange_anti_phish_policy_deletion.toml +++ b/rules/integrations/o365/defense_evasion_exchange_anti_phish_policy_deletion.toml @@ -2,7 +2,7 @@ creation_date = "2020/11/19" integration = ["o365"] maturity = "production" -updated_date = "2025/09/30" +updated_date = "2025/10/01" [rule] author = ["Elastic"] @@ -21,13 +21,13 @@ from = "now-9m" index = ["logs-o365.audit-*", "filebeat-*"] language = "kuery" license = "Elastic License v2" -name = "Microsoft 365 Exchange Anti-Phish Policy Deletion" +name = "M365 Exchange Anti-Phish Policy Deleted" 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 Microsoft 365 Exchange Anti-Phish Policy Deletion +### Investigating M365 Exchange Anti-Phish Policy Deleted Microsoft 365's anti-phishing policies enhance security by fine-tuning detection settings to thwart phishing attacks. Adversaries may delete these policies to weaken defenses, facilitating unauthorized access. The detection rule monitors audit logs for successful deletions of anti-phishing policies, signaling potential malicious activity by identifying specific actions and outcomes associated with policy removal. diff --git a/rules/integrations/o365/defense_evasion_microsoft_365_exchange_anti_phish_rule_mod.toml b/rules/integrations/o365/defense_evasion_exchange_anti_phish_rule_modification.toml similarity index 97% rename from rules/integrations/o365/defense_evasion_microsoft_365_exchange_anti_phish_rule_mod.toml rename to rules/integrations/o365/defense_evasion_exchange_anti_phish_rule_modification.toml index 3fc48d39708..22828f60916 100644 --- a/rules/integrations/o365/defense_evasion_microsoft_365_exchange_anti_phish_rule_mod.toml +++ b/rules/integrations/o365/defense_evasion_exchange_anti_phish_rule_modification.toml @@ -2,7 +2,7 @@ creation_date = "2020/11/19" integration = ["o365"] maturity = "production" -updated_date = "2025/09/30" +updated_date = "2025/10/01" [rule] author = ["Elastic"] @@ -21,13 +21,13 @@ from = "now-9m" index = ["logs-o365.audit-*", "filebeat-*"] language = "kuery" license = "Elastic License v2" -name = "Microsoft 365 Exchange Anti-Phish Rule Modification" +name = "M365 Exchange Anti-Phish Rule Modification" 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 Microsoft 365 Exchange Anti-Phish Rule Modification +### Investigating M365 Exchange Anti-Phish Rule Modification Microsoft 365's anti-phishing rules are crucial for safeguarding users against phishing attacks by enhancing detection and prevention settings. Adversaries may attempt to modify or disable these rules to facilitate phishing campaigns, gaining unauthorized access. The detection rule monitors for successful modifications or disabling of anti-phishing rules, signaling potential malicious activity by tracking specific actions within the Exchange environment. diff --git a/rules/integrations/o365/defense_evasion_microsoft_365_exchange_dkim_signing_config_disabled.toml b/rules/integrations/o365/defense_evasion_exchange_dkim_signing_config_disabled.toml similarity index 97% rename from rules/integrations/o365/defense_evasion_microsoft_365_exchange_dkim_signing_config_disabled.toml rename to rules/integrations/o365/defense_evasion_exchange_dkim_signing_config_disabled.toml index 0a2a4beeef7..e72e70689ec 100644 --- a/rules/integrations/o365/defense_evasion_microsoft_365_exchange_dkim_signing_config_disabled.toml +++ b/rules/integrations/o365/defense_evasion_exchange_dkim_signing_config_disabled.toml @@ -2,7 +2,7 @@ creation_date = "2020/11/18" integration = ["o365"] maturity = "production" -updated_date = "2025/09/30" +updated_date = "2025/10/01" [rule] author = ["Elastic"] @@ -22,13 +22,13 @@ from = "now-9m" index = ["logs-o365.audit-*", "filebeat-*"] language = "kuery" license = "Elastic License v2" -name = "Microsoft 365 Exchange DKIM Signing Configuration Disabled" +name = "M365 Exchange DKIM Signing Configuration Disabled" 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 Microsoft 365 Exchange DKIM Signing Configuration Disabled +### Investigating M365 Exchange DKIM Signing Configuration Disabled DomainKeys Identified Mail (DKIM) is a security protocol that ensures email authenticity by allowing recipients to verify that messages are sent from authorized servers. Disabling DKIM can expose organizations to email spoofing, where attackers impersonate legitimate domains to conduct phishing attacks. The detection rule identifies when DKIM is disabled in Microsoft 365, signaling potential unauthorized changes that could facilitate persistent threats. diff --git a/rules/integrations/o365/defense_evasion_microsoft_365_exchange_dlp_policy_removed.toml b/rules/integrations/o365/defense_evasion_exchange_dlp_policy_removed.toml similarity index 97% rename from rules/integrations/o365/defense_evasion_microsoft_365_exchange_dlp_policy_removed.toml rename to rules/integrations/o365/defense_evasion_exchange_dlp_policy_removed.toml index d5e1083e4e6..ac660422cdb 100644 --- a/rules/integrations/o365/defense_evasion_microsoft_365_exchange_dlp_policy_removed.toml +++ b/rules/integrations/o365/defense_evasion_exchange_dlp_policy_removed.toml @@ -2,7 +2,7 @@ creation_date = "2020/11/20" integration = ["o365"] maturity = "production" -updated_date = "2025/09/26" +updated_date = "2025/10/01" [rule] author = ["Elastic"] @@ -20,13 +20,13 @@ from = "now-9m" index = ["logs-o365.audit-*", "filebeat-*"] language = "kuery" license = "Elastic License v2" -name = "Microsoft 365 Exchange DLP Policy Removed" +name = "M365 Exchange DLP Policy Deleted" 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 Microsoft 365 Exchange DLP Policy Removed +### Investigating M365 Exchange DLP Policy Deleted Data Loss Prevention (DLP) in Microsoft 365 Exchange is crucial for safeguarding sensitive information by monitoring and controlling data transfers. Adversaries may exploit this by removing DLP policies to bypass data monitoring, facilitating unauthorized data exfiltration. The detection rule identifies such actions by analyzing audit logs for specific events indicating successful DLP policy removal, thus alerting security teams to potential defense evasion tactics. diff --git a/rules/integrations/o365/defense_evasion_microsoft_365_exchange_safelinks_disabled.toml b/rules/integrations/o365/defense_evasion_exchange_exchange_safelinks_disabled.toml similarity index 97% rename from rules/integrations/o365/defense_evasion_microsoft_365_exchange_safelinks_disabled.toml rename to rules/integrations/o365/defense_evasion_exchange_exchange_safelinks_disabled.toml index 5bfd1f880b6..5bc37f48872 100644 --- a/rules/integrations/o365/defense_evasion_microsoft_365_exchange_safelinks_disabled.toml +++ b/rules/integrations/o365/defense_evasion_exchange_exchange_safelinks_disabled.toml @@ -2,7 +2,7 @@ creation_date = "2020/11/18" integration = ["o365"] maturity = "production" -updated_date = "2025/09/30" +updated_date = "2025/10/01" [rule] author = ["Elastic"] @@ -20,13 +20,13 @@ from = "now-9m" index = ["logs-o365.audit-*", "filebeat-*"] language = "kuery" license = "Elastic License v2" -name = "Microsoft 365 Exchange Safe Link Policy Disabled" +name = "M365 Exchange Email Safe Link Policy Disabled" 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 Microsoft 365 Exchange Safe Link Policy Disabled +### Investigating M365 Exchange Email Safe Link Policy Disabled Microsoft 365's Safe Link policies enhance security by scanning hyperlinks in documents for phishing threats, even post-delivery. Disabling these policies can expose users to phishing attacks. Adversaries might exploit this by disabling Safe Links to facilitate malicious link delivery. The detection rule identifies successful attempts to disable Safe Link policies, signaling potential security breaches. diff --git a/rules/integrations/o365/defense_evasion_microsoft_365_mailboxauditbypassassociation.toml b/rules/integrations/o365/defense_evasion_exchange_mailbox_audit_bypass_association.toml similarity index 97% rename from rules/integrations/o365/defense_evasion_microsoft_365_mailboxauditbypassassociation.toml rename to rules/integrations/o365/defense_evasion_exchange_mailbox_audit_bypass_association.toml index 5d38ed18549..1e4d9dde0b0 100644 --- a/rules/integrations/o365/defense_evasion_microsoft_365_mailboxauditbypassassociation.toml +++ b/rules/integrations/o365/defense_evasion_exchange_mailbox_audit_bypass_association.toml @@ -2,7 +2,7 @@ creation_date = "2022/01/13" integration = ["o365"] maturity = "production" -updated_date = "2025/09/30" +updated_date = "2025/10/01" [rule] author = ["Elastic"] @@ -20,13 +20,13 @@ from = "now-9m" index = ["logs-o365.audit-*", "filebeat-*"] language = "kuery" license = "Elastic License v2" -name = "O365 Mailbox Audit Logging Bypass" +name = "M365 Exchange Mailbox Audit Logging Bypass Added" 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 O365 Mailbox Audit Logging Bypass +### Investigating M365 Exchange Mailbox Audit Logging Bypass Added In Microsoft 365 environments, mailbox audit logging is crucial for tracking user activities like accessing or deleting emails. However, administrators can exempt certain accounts from logging to reduce noise, which attackers might exploit to hide their actions. The detection rule identifies successful attempts to create such exemptions, signaling potential misuse of this bypass mechanism. diff --git a/rules/integrations/o365/defense_evasion_microsoft_365_exchange_malware_filter_policy_deletion.toml b/rules/integrations/o365/defense_evasion_exchange_malware_filter_policy_deletion.toml similarity index 97% rename from rules/integrations/o365/defense_evasion_microsoft_365_exchange_malware_filter_policy_deletion.toml rename to rules/integrations/o365/defense_evasion_exchange_malware_filter_policy_deletion.toml index 4d836f3e117..f84535f0418 100644 --- a/rules/integrations/o365/defense_evasion_microsoft_365_exchange_malware_filter_policy_deletion.toml +++ b/rules/integrations/o365/defense_evasion_exchange_malware_filter_policy_deletion.toml @@ -2,7 +2,7 @@ creation_date = "2020/11/19" integration = ["o365"] maturity = "production" -updated_date = "2025/09/26" +updated_date = "2025/10/01" [rule] author = ["Elastic"] @@ -21,13 +21,13 @@ from = "now-9m" index = ["logs-o365.audit-*", "filebeat-*"] language = "kuery" license = "Elastic License v2" -name = "Microsoft 365 Exchange Malware Filter Policy Deletion" +name = "M365 Exchange Malware Filter Policy Deleted" 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 Microsoft 365 Exchange Malware Filter Policy Deletion +### Investigating M365 Exchange Malware Filter Policy Deleted Microsoft 365 Exchange uses malware filter policies to detect and alert administrators about malware in emails, crucial for maintaining security. Adversaries may delete these policies to bypass detection, facilitating undetected malware distribution. The detection rule monitors audit logs for successful deletions of these policies, signaling potential defense evasion attempts. diff --git a/rules/integrations/o365/defense_evasion_microsoft_365_exchange_malware_filter_rule_mod.toml b/rules/integrations/o365/defense_evasion_exchange_malware_filter_rule_mod.toml similarity index 97% rename from rules/integrations/o365/defense_evasion_microsoft_365_exchange_malware_filter_rule_mod.toml rename to rules/integrations/o365/defense_evasion_exchange_malware_filter_rule_mod.toml index 79b64b231c6..8ea97495be6 100644 --- a/rules/integrations/o365/defense_evasion_microsoft_365_exchange_malware_filter_rule_mod.toml +++ b/rules/integrations/o365/defense_evasion_exchange_malware_filter_rule_mod.toml @@ -2,7 +2,7 @@ creation_date = "2020/11/19" integration = ["o365"] maturity = "production" -updated_date = "2025/09/26" +updated_date = "2025/10/01" [rule] author = ["Elastic"] @@ -20,13 +20,13 @@ from = "now-9m" index = ["logs-o365.audit-*", "filebeat-*"] language = "kuery" license = "Elastic License v2" -name = "Microsoft 365 Exchange Malware Filter Rule Modification" +name = "M365 Exchange Malware Filter Rule Modified" 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 Microsoft 365 Exchange Malware Filter Rule Modification +### Investigating M365 Exchange Malware Filter Rule Modified Microsoft 365 Exchange uses malware filter rules to protect email systems by identifying and blocking malicious content. Adversaries may attempt to disable or remove these rules to bypass security measures and facilitate attacks. The detection rule monitors audit logs for successful actions that alter these rules, signaling potential defense evasion tactics. This helps security analysts quickly identify and respond to unauthorized modifications. diff --git a/rules/integrations/o365/defense_evasion_microsoft_365_new_inbox_rule_delete_or_move.toml b/rules/integrations/o365/defense_evasion_exchange_new_inbox_rule_delete_or_move.toml similarity index 96% rename from rules/integrations/o365/defense_evasion_microsoft_365_new_inbox_rule_delete_or_move.toml rename to rules/integrations/o365/defense_evasion_exchange_new_inbox_rule_delete_or_move.toml index ad4b52badf0..e3d64fb5ae9 100644 --- a/rules/integrations/o365/defense_evasion_microsoft_365_new_inbox_rule_delete_or_move.toml +++ b/rules/integrations/o365/defense_evasion_exchange_new_inbox_rule_delete_or_move.toml @@ -2,7 +2,7 @@ creation_date = "2025/05/22" integration = ["o365"] maturity = "production" -updated_date = "2025/05/22" +updated_date = "2025/10/01" [rule] author = ["Elastic", "Jamie Lee"] @@ -17,10 +17,10 @@ from = "now-9m" index = ["filebeat-*", "logs-o365.audit-*"] language = "kuery" license = "Elastic License v2" -name = "Microsoft 365 Suspicious Inbox Rule to Delete or Move Emails" +name = "M365 Exchange Inbox Phishing Evasion Rule Created" note = """## Triage and Analysis -### Investigating Microsoft 365 Suspicious Inbox Rule to Delete or Move Emails +### Investigating M365 Exchange Inbox Phishing Evasion Rule Created This detection identifies the creation of potentially malicious inbox rules in Microsoft 365. These rules automatically delete or move emails with specific keywords such as "invoice", "payment", "security", or "phish". Adversaries often use these rules post-compromise to conceal warning emails, alerts from security tools, or responses from help desk teams, thereby evading detection and maintaining access. diff --git a/rules/integrations/o365/defense_evasion_microsoft_365_exchange_safe_attach_rule_disabled.toml b/rules/integrations/o365/defense_evasion_exchange_safe_attach_rule_disabled.toml similarity index 97% rename from rules/integrations/o365/defense_evasion_microsoft_365_exchange_safe_attach_rule_disabled.toml rename to rules/integrations/o365/defense_evasion_exchange_safe_attach_rule_disabled.toml index 12d720af219..235e92f82e0 100644 --- a/rules/integrations/o365/defense_evasion_microsoft_365_exchange_safe_attach_rule_disabled.toml +++ b/rules/integrations/o365/defense_evasion_exchange_safe_attach_rule_disabled.toml @@ -2,7 +2,7 @@ creation_date = "2020/11/19" integration = ["o365"] maturity = "production" -updated_date = "2025/09/26" +updated_date = "2025/10/01" [rule] author = ["Elastic"] @@ -21,13 +21,13 @@ from = "now-9m" index = ["logs-o365.audit-*", "filebeat-*"] language = "kuery" license = "Elastic License v2" -name = "Microsoft 365 Exchange Safe Attachment Rule Disabled" +name = "M365 Exchange Email Safe Attachment Rule Disabled" 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 Microsoft 365 Exchange Safe Attachment Rule Disabled +### Investigating M365 Exchange Email Safe Attachment Rule Disabled Microsoft 365's Safe Attachment feature enhances security by analyzing email attachments in a secure environment to detect unknown malware. Disabling this rule can expose organizations to threats by allowing potentially harmful attachments to bypass scrutiny. Adversaries may exploit this to exfiltrate data or avoid detection. The detection rule monitors audit logs for successful attempts to disable this feature, signaling potential defense evasion activities. diff --git a/rules/integrations/o365/defense_evasion_microsoft_365_teams_custom_app_interaction_allowed.toml b/rules/integrations/o365/defense_evasion_teams_custom_app_interaction_allowed.toml similarity index 97% rename from rules/integrations/o365/defense_evasion_microsoft_365_teams_custom_app_interaction_allowed.toml rename to rules/integrations/o365/defense_evasion_teams_custom_app_interaction_allowed.toml index da9c9dbb909..892e651f3db 100644 --- a/rules/integrations/o365/defense_evasion_microsoft_365_teams_custom_app_interaction_allowed.toml +++ b/rules/integrations/o365/defense_evasion_teams_custom_app_interaction_allowed.toml @@ -2,7 +2,7 @@ creation_date = "2020/11/30" integration = ["o365"] maturity = "production" -updated_date = "2025/09/30" +updated_date = "2025/10/01" [rule] author = ["Elastic"] @@ -21,13 +21,13 @@ from = "now-9m" index = ["logs-o365.audit-*", "filebeat-*"] language = "kuery" license = "Elastic License v2" -name = "Microsoft 365 Teams Custom Application Interaction Allowed" +name = "M365 Teams Custom Application Interaction Enabled" 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 Microsoft 365 Teams Custom Application Interaction Allowed +### Investigating M365 Teams Custom Application Interaction Enabled Microsoft Teams allows organizations to enhance functionality by integrating custom applications, which can be developed and uploaded beyond the standard app store offerings. While beneficial for tailored solutions, this capability can be exploited by adversaries to maintain unauthorized access. The detection rule monitors changes in tenant settings that permit custom app interactions, flagging successful modifications as potential persistence threats. diff --git a/rules/integrations/o365/defense_evasion_microsoft_365_teams_external_access_enabled.toml b/rules/integrations/o365/defense_evasion_teams_external_access_enabled.toml similarity index 97% rename from rules/integrations/o365/defense_evasion_microsoft_365_teams_external_access_enabled.toml rename to rules/integrations/o365/defense_evasion_teams_external_access_enabled.toml index ee006ed372e..2981affa9c3 100644 --- a/rules/integrations/o365/defense_evasion_microsoft_365_teams_external_access_enabled.toml +++ b/rules/integrations/o365/defense_evasion_teams_external_access_enabled.toml @@ -2,7 +2,7 @@ creation_date = "2020/11/30" integration = ["o365"] maturity = "production" -updated_date = "2025/09/30" +updated_date = "2025/10/01" [rule] author = ["Elastic"] @@ -21,13 +21,13 @@ from = "now-9m" index = ["logs-o365.audit-*", "filebeat-*"] language = "kuery" license = "Elastic License v2" -name = "Microsoft 365 Teams External Access Enabled" +name = "M365 Teams External Access Enabled" 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 Microsoft 365 Teams External Access Enabled +### Investigating M365 Teams External Access Enabled Microsoft Teams' external access feature allows users to communicate with individuals outside their organization, facilitating collaboration. However, adversaries can exploit this by enabling external access or adding trusted domains to exfiltrate data or maintain persistence. The detection rule monitors audit logs for changes in federation settings, specifically when external access is successfully enabled, indicating potential misuse. diff --git a/rules/integrations/o365/exfiltration_microsoft_365_exchange_transport_rule_creation.toml b/rules/integrations/o365/exfiltration_exchange_transport_rule_creation.toml similarity index 97% rename from rules/integrations/o365/exfiltration_microsoft_365_exchange_transport_rule_creation.toml rename to rules/integrations/o365/exfiltration_exchange_transport_rule_creation.toml index cf35e212f2f..fa79834a063 100644 --- a/rules/integrations/o365/exfiltration_microsoft_365_exchange_transport_rule_creation.toml +++ b/rules/integrations/o365/exfiltration_exchange_transport_rule_creation.toml @@ -2,7 +2,7 @@ creation_date = "2020/11/18" integration = ["o365"] maturity = "production" -updated_date = "2025/09/26" +updated_date = "2025/10/01" [rule] author = ["Elastic"] @@ -21,13 +21,13 @@ from = "now-9m" index = ["logs-o365.audit-*", "filebeat-*"] language = "kuery" license = "Elastic License v2" -name = "Microsoft 365 Exchange Transport Rule Creation" +name = "M365 Exchange Mail Flow Transport Rule Created" 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 Microsoft 365 Exchange Transport Rule Creation +### Investigating M365 Exchange Mail Flow Transport Rule Created Microsoft 365 Exchange transport rules automate email handling, applying actions like forwarding or blocking based on conditions. While beneficial for managing communications, adversaries can exploit these rules to redirect emails externally, facilitating data exfiltration. The detection rule monitors successful creation of new transport rules, flagging potential misuse by identifying specific actions and outcomes in audit logs. diff --git a/rules/integrations/o365/exfiltration_microsoft_365_exchange_transport_rule_mod.toml b/rules/integrations/o365/exfiltration_exchange_transport_rule_modification.toml similarity index 97% rename from rules/integrations/o365/exfiltration_microsoft_365_exchange_transport_rule_mod.toml rename to rules/integrations/o365/exfiltration_exchange_transport_rule_modification.toml index 394b20f0e86..b9e89deb568 100644 --- a/rules/integrations/o365/exfiltration_microsoft_365_exchange_transport_rule_mod.toml +++ b/rules/integrations/o365/exfiltration_exchange_transport_rule_modification.toml @@ -2,7 +2,7 @@ creation_date = "2020/11/19" integration = ["o365"] maturity = "production" -updated_date = "2025/09/26" +updated_date = "2025/10/01" [rule] author = ["Elastic"] @@ -21,13 +21,13 @@ from = "now-9m" index = ["logs-o365.audit-*", "filebeat-*"] language = "kuery" license = "Elastic License v2" -name = "Microsoft 365 Exchange Transport Rule Modification" +name = "M365 Exchange Mail Flow Transport Rule Modified" 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 Microsoft 365 Exchange Transport Rule Modification +### Investigating M365 Exchange Mail Flow Transport Rule Modified Microsoft 365 Exchange transport rules manage email flow by setting conditions and actions for messages. Adversaries may exploit these rules to disable or delete them, facilitating data exfiltration or bypassing security measures. The detection rule monitors audit logs for successful execution of commands that alter these rules, signaling potential misuse and enabling timely investigation. diff --git a/rules/integrations/o365/impact_microsoft_365_potential_ransomware_activity.toml b/rules/integrations/o365/impact_security_compliance_potential_ransomware_activity.toml similarity index 97% rename from rules/integrations/o365/impact_microsoft_365_potential_ransomware_activity.toml rename to rules/integrations/o365/impact_security_compliance_potential_ransomware_activity.toml index 8cbb99d4fdd..2e6c9525976 100644 --- a/rules/integrations/o365/impact_microsoft_365_potential_ransomware_activity.toml +++ b/rules/integrations/o365/impact_security_compliance_potential_ransomware_activity.toml @@ -2,7 +2,7 @@ creation_date = "2021/07/15" integration = ["o365"] maturity = "production" -updated_date = "2025/09/26" +updated_date = "2025/10/01" [rule] author = ["Austin Songer"] @@ -20,13 +20,13 @@ from = "now-9m" index = ["logs-o365.audit-*", "filebeat-*"] language = "kuery" license = "Elastic License v2" -name = "Microsoft 365 Potential ransomware activity" +name = "M365 Security Compliance Potential Ransomware Activity" 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 Microsoft 365 Potential ransomware activity +### Investigating M365 Security Compliance Potential Ransomware Activity Microsoft 365's cloud services can be exploited by adversaries to distribute ransomware by uploading infected files. This detection rule leverages Microsoft Cloud App Security to identify suspicious uploads, focusing on successful events flagged as potential ransomware activity. By monitoring specific event datasets and actions, it helps security analysts pinpoint and mitigate ransomware threats, aligning with MITRE ATT&CK's impact tactics. diff --git a/rules/integrations/o365/impact_microsoft_365_unusual_volume_of_file_deletion.toml b/rules/integrations/o365/impact_security_compliance_unusual_volume_of_file_deletion.toml similarity index 97% rename from rules/integrations/o365/impact_microsoft_365_unusual_volume_of_file_deletion.toml rename to rules/integrations/o365/impact_security_compliance_unusual_volume_of_file_deletion.toml index cccf432b3a3..24d45939f71 100644 --- a/rules/integrations/o365/impact_microsoft_365_unusual_volume_of_file_deletion.toml +++ b/rules/integrations/o365/impact_security_compliance_unusual_volume_of_file_deletion.toml @@ -2,7 +2,7 @@ creation_date = "2021/07/15" integration = ["o365"] maturity = "production" -updated_date = "2025/09/26" +updated_date = "2025/10/01" [rule] author = ["Austin Songer"] @@ -12,13 +12,13 @@ from = "now-9m" index = ["logs-o365.audit-*", "filebeat-*"] language = "kuery" license = "Elastic License v2" -name = "Microsoft 365 Unusual Volume of File Deletion" +name = "M365 Security Compliance Unusual Volume of File Deletion" 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 Microsoft 365 Unusual Volume of File Deletion +### Investigating M365 Security Compliance Unusual Volume of File Deletion Microsoft 365's cloud environment facilitates file storage and collaboration, but its vast data handling capabilities can be exploited by adversaries for data destruction. Attackers may delete large volumes of files to disrupt operations or cover their tracks. The detection rule leverages audit logs to identify anomalies in file deletion activities, flagging successful, unusual deletion volumes as potential security incidents, thus enabling timely investigation and response. diff --git a/rules/integrations/o365/initial_access_entra_id_portal_login_atypical_travel.toml b/rules/integrations/o365/initial_access_entra_id_portal_login_atypical_travel.toml index ddf1a85f365..843b73b9f81 100644 --- a/rules/integrations/o365/initial_access_entra_id_portal_login_atypical_travel.toml +++ b/rules/integrations/o365/initial_access_entra_id_portal_login_atypical_travel.toml @@ -2,7 +2,7 @@ creation_date = "2024/09/04" integration = ["o365"] maturity = "production" -updated_date = "2025/09/08" +updated_date = "2025/10/01" [rule] author = ["Elastic"] @@ -23,10 +23,10 @@ from = "now-15m" index = ["logs-o365.audit-*"] language = "kuery" license = "Elastic License v2" -name = "M365 Portal Login (Atypical Travel)" +name = "M365 Identity Portal Login (Atypical Travel)" note = """## Triage and analysis -### Investigating M365 Portal Login (Atypical Travel) +### Investigating M365 Identity Portal Login (Atypical Travel) Microsoft 365 is a cloud-based suite offering productivity tools accessible from anywhere, making it crucial for business operations. Adversaries may exploit this by logging in from uncommon locations, potentially using VPNs to mask their origin. The detection rule identifies successful logins from atypical locations, flagging potential unauthorized access attempts by analyzing login events and user location patterns. diff --git a/rules/integrations/o365/initial_access_entra_id_portal_login_impossible_travel.toml b/rules/integrations/o365/initial_access_entra_id_portal_login_impossible_travel.toml index 820eb3fdf1c..c28ec14a29a 100644 --- a/rules/integrations/o365/initial_access_entra_id_portal_login_impossible_travel.toml +++ b/rules/integrations/o365/initial_access_entra_id_portal_login_impossible_travel.toml @@ -2,7 +2,7 @@ creation_date = "2024/09/04" integration = ["o365"] maturity = "production" -updated_date = "2025/09/08" +updated_date = "2025/10/01" [rule] author = ["Elastic"] @@ -22,10 +22,10 @@ from = "now-15m" index = ["logs-o365.audit-*"] language = "kuery" license = "Elastic License v2" -name = "M365 Portal Login (Impossible Travel)" +name = "M365 Identity Portal Login (Impossible Travel)" note = """## Triage and analysis -### Investigating M365 Portal Login (Impossible Travel) +### Investigating M365 Identity Portal Login (Impossible Travel) Microsoft 365's cloud-based services enable global access, but this can be exploited by adversaries logging in from disparate locations within short intervals, indicating potential account compromise. The detection rule identifies such anomalies by analyzing login events for rapid geographic shifts, flagging suspicious activity that may suggest unauthorized access attempts. diff --git a/rules/integrations/o365/initial_access_microsoft_365_illicit_consent_grant_via_registered_application.toml b/rules/integrations/o365/initial_access_identity_illicit_consent_grant_via_registered_application.toml similarity index 97% rename from rules/integrations/o365/initial_access_microsoft_365_illicit_consent_grant_via_registered_application.toml rename to rules/integrations/o365/initial_access_identity_illicit_consent_grant_via_registered_application.toml index a3ac7c54f45..7bfd1f77863 100644 --- a/rules/integrations/o365/initial_access_microsoft_365_illicit_consent_grant_via_registered_application.toml +++ b/rules/integrations/o365/initial_access_identity_illicit_consent_grant_via_registered_application.toml @@ -2,7 +2,7 @@ creation_date = "2025/03/24" integration = ["o365"] maturity = "production" -updated_date = "2025/09/26" +updated_date = "2025/10/01" [rule] author = ["Elastic"] @@ -17,10 +17,10 @@ from = "now-9m" index = ["logs-o365.audit-*"] language = "kuery" license = "Elastic License v2" -name = "Microsoft 365 Illicit Consent Grant via Registered Application" +name = "M365 Identity OAuth Illicit Consent Grant by Rare Client and User" note = """## Triage and analysis -### Investigating Microsoft 365 Illicit Consent Grant via Registered Application +### Investigating M365 Identity OAuth Illicit Consent Grant by Rare Client and User Adversaries may register a malicious application in Microsoft Entra ID and trick users into granting excessive permissions via OAuth consent. These apps can access sensitive Microsoft 365 data—such as mail, profiles, and files—on behalf of the user once consent is granted. This activity is often initiated through spearphishing campaigns that direct the user to a pre-crafted OAuth consent URL. diff --git a/rules/integrations/o365/initial_access_microsoft_365_entra_oauth_phishing_via_vscode_client.toml b/rules/integrations/o365/initial_access_identity_oauth_phishing_via_vscode_client.toml similarity index 97% rename from rules/integrations/o365/initial_access_microsoft_365_entra_oauth_phishing_via_vscode_client.toml rename to rules/integrations/o365/initial_access_identity_oauth_phishing_via_vscode_client.toml index 6970f588e0e..af14942fa0b 100644 --- a/rules/integrations/o365/initial_access_microsoft_365_entra_oauth_phishing_via_vscode_client.toml +++ b/rules/integrations/o365/initial_access_identity_oauth_phishing_via_vscode_client.toml @@ -2,7 +2,7 @@ creation_date = "2025/04/23" integration = ["o365"] maturity = "production" -updated_date = "2025/09/08" +updated_date = "2025/10/01" [rule] author = ["Elastic"] @@ -19,10 +19,10 @@ from = "now-25m" index = ["logs-o365.audit-*"] language = "kuery" license = "Elastic License v2" -name = "Microsoft 365 OAuth Phishing via Visual Studio Code Client" +name = "M365 Identity OAuth Flow by Visual Studio Code Client to Microsoft Graph" note = """## Triage and analysis -### Investigating Microsoft 365 OAuth Phishing via Visual Studio Code Client +### Investigating M365 Identity OAuth Flow by Visual Studio Code Client to Microsoft Graph This rule identifies successful Microsoft 365 sign-ins where the Visual Studio Code first-party application (`ApplicationId = aebc6443-996d-45c2-90f0-388ff96faa56`) was used to initiate an OAuth 2.0 authorization code flow targeting Microsoft Graph. While this is common for legitimate development workflows, it has been abused in real-world phishing campaigns to trick users into returning authorization codes that attackers can exchange for access tokens. diff --git a/rules/integrations/o365/initial_access_o365_user_reported_phish_malware.toml b/rules/integrations/o365/initial_access_security_compliance_user_reported_phish_malware.toml similarity index 97% rename from rules/integrations/o365/initial_access_o365_user_reported_phish_malware.toml rename to rules/integrations/o365/initial_access_security_compliance_user_reported_phish_malware.toml index 836528e8658..2c0005cd87f 100644 --- a/rules/integrations/o365/initial_access_o365_user_reported_phish_malware.toml +++ b/rules/integrations/o365/initial_access_security_compliance_user_reported_phish_malware.toml @@ -2,7 +2,7 @@ creation_date = "2022/01/12" integration = ["o365"] maturity = "production" -updated_date = "2025/09/26" +updated_date = "2025/10/01" [rule] author = ["Elastic"] @@ -17,13 +17,13 @@ from = "now-9m" index = ["logs-o365.audit-*", "filebeat-*"] language = "kuery" license = "Elastic License v2" -name = "O365 Email Reported by User as Malware or Phish" +name = "M365 Security Compliance Email Reported by User as Malware or Phish" 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 O365 Email Reported by User as Malware or Phish +### Investigating M365 Security Compliance Email Reported by User as Malware or Phish Microsoft 365's email services are integral to business communication, but they can be exploited by adversaries through phishing or malware-laden emails. Attackers may bypass security measures, reaching users who might unwittingly engage with malicious content. The detection rule leverages user reports of suspicious emails, correlating them with security events to identify potential threats, thus enhancing the organization's ability to respond to phishing attempts and malware distribution. diff --git a/rules/integrations/o365/initial_access_microsoft_365_user_restricted_from_sending_email.toml b/rules/integrations/o365/initial_access_security_compliance_user_restricted_from_sending_email.toml similarity index 96% rename from rules/integrations/o365/initial_access_microsoft_365_user_restricted_from_sending_email.toml rename to rules/integrations/o365/initial_access_security_compliance_user_restricted_from_sending_email.toml index 71ba32be451..3f0b419e967 100644 --- a/rules/integrations/o365/initial_access_microsoft_365_user_restricted_from_sending_email.toml +++ b/rules/integrations/o365/initial_access_security_compliance_user_restricted_from_sending_email.toml @@ -2,7 +2,7 @@ creation_date = "2021/07/15" integration = ["o365"] maturity = "production" -updated_date = "2025/09/30" +updated_date = "2025/10/01" [rule] author = ["Austin Songer"] @@ -15,13 +15,13 @@ from = "now-9m" index = ["logs-o365.audit-*", "filebeat-*"] language = "kuery" license = "Elastic License v2" -name = "Microsoft 365 User Restricted from Sending Email" +name = "M365 Security Compliance User Restricted from Sending Email" 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 Microsoft 365 User Restricted from Sending Email +### Investigating M365 Security Compliance User Restricted from Sending Email Microsoft 365 enforces email sending limits to prevent abuse and ensure service integrity. Adversaries may exploit compromised accounts to send spam or phishing emails, triggering these limits. The detection rule monitors audit logs for successful restrictions by the Security Compliance Center, indicating potential misuse of valid accounts, aligning with MITRE ATT&CK's Initial Access tactic. diff --git a/rules/integrations/o365/lateral_movement_malware_uploaded_onedrive.toml b/rules/integrations/o365/lateral_movement_onedrive_malware_uploaded.toml similarity index 98% rename from rules/integrations/o365/lateral_movement_malware_uploaded_onedrive.toml rename to rules/integrations/o365/lateral_movement_onedrive_malware_uploaded.toml index b09969996f1..bf19763ce76 100644 --- a/rules/integrations/o365/lateral_movement_malware_uploaded_onedrive.toml +++ b/rules/integrations/o365/lateral_movement_onedrive_malware_uploaded.toml @@ -2,7 +2,7 @@ creation_date = "2022/01/10" integration = ["o365"] maturity = "production" -updated_date = "2025/09/30" +updated_date = "2025/10/01" [rule] author = ["Elastic"] @@ -17,13 +17,13 @@ from = "now-9m" index = ["logs-o365.audit-*", "filebeat-*"] language = "kuery" license = "Elastic License v2" -name = "OneDrive Malware File Upload" +name = "M365 OneDrive Malware File Upload" 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 OneDrive Malware File Upload +### Investigating M365 OneDrive Malware File Upload OneDrive, a cloud storage service, facilitates file sharing and collaboration within organizations. However, adversaries can exploit this by uploading malware, which can spread across shared environments, leading to lateral movement within a network. The detection rule identifies such threats by monitoring OneDrive activities for malware detection events, focusing on file operations flagged by Microsoft's security engine. This proactive approach helps in identifying and mitigating potential breaches. diff --git a/rules/integrations/o365/lateral_movement_malware_uploaded_sharepoint.toml b/rules/integrations/o365/lateral_movement_sharepoint_malware_uploaded.toml similarity index 98% rename from rules/integrations/o365/lateral_movement_malware_uploaded_sharepoint.toml rename to rules/integrations/o365/lateral_movement_sharepoint_malware_uploaded.toml index 76d1ad4fafc..a9d7f102ebe 100644 --- a/rules/integrations/o365/lateral_movement_malware_uploaded_sharepoint.toml +++ b/rules/integrations/o365/lateral_movement_sharepoint_malware_uploaded.toml @@ -2,7 +2,7 @@ creation_date = "2022/01/10" integration = ["o365"] maturity = "production" -updated_date = "2025/09/30" +updated_date = "2025/10/01" [rule] author = ["Elastic"] @@ -17,13 +17,13 @@ from = "now-9m" index = ["logs-o365.audit-*", "filebeat-*"] language = "kuery" license = "Elastic License v2" -name = "SharePoint Malware File Upload" +name = "M365 SharePoint Malware File Detected" 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 SharePoint Malware File Upload +### Investigating M365 SharePoint Malware File Detected SharePoint, a collaborative platform, facilitates file sharing and storage within organizations. Adversaries exploit this by uploading malware, leveraging the platform's sharing capabilities to propagate threats laterally. The detection rule identifies when SharePoint's file scanning engine flags an upload as malicious, focusing on specific audit events to alert security teams of potential lateral movement threats. diff --git a/rules/integrations/o365/persistence_microsoft_365_global_administrator_role_assign.toml b/rules/integrations/o365/persistence_entra_id_global_administrator_role_assign.toml similarity index 97% rename from rules/integrations/o365/persistence_microsoft_365_global_administrator_role_assign.toml rename to rules/integrations/o365/persistence_entra_id_global_administrator_role_assign.toml index 46e3a33ef4b..a9fbde5a7c5 100644 --- a/rules/integrations/o365/persistence_microsoft_365_global_administrator_role_assign.toml +++ b/rules/integrations/o365/persistence_entra_id_global_administrator_role_assign.toml @@ -2,7 +2,7 @@ creation_date = "2022/01/06" integration = ["o365"] maturity = "production" -updated_date = "2025/09/08" +updated_date = "2025/10/01" [rule] author = ["Elastic"] @@ -17,10 +17,10 @@ from = "now-9m" index = ["logs-o365.audit-*"] language = "kuery" license = "Elastic License v2" -name = "Microsoft 365 Global Administrator Role Assigned" +name = "M365 Identity Global Administrator Role Assigned" note = """## Triage and Analysis -### Investigating Microsoft 365 Global Administrator Role Assigned +### Investigating M365 Identity Global Administrator Role Assigned The Microsoft 365 Global Administrator role grants comprehensive administrative access across Entra ID and services such as Microsoft 365 Defender, Exchange, SharePoint, and Skype for Business. Adversaries who compromise an account may assign this role to themselves or other users to ensure persistent and privileged access. This rule identifies successful assignments of this role by inspecting audit logs from Azure Active Directory (Entra ID) where the role display name matches "Administrator." diff --git a/rules/integrations/o365/persistence_microsoft_365_exchange_management_role_assignment.toml b/rules/integrations/o365/persistence_exchange_management_role_assignment.toml similarity index 97% rename from rules/integrations/o365/persistence_microsoft_365_exchange_management_role_assignment.toml rename to rules/integrations/o365/persistence_exchange_management_role_assignment.toml index af290642ec2..913fa07bc31 100644 --- a/rules/integrations/o365/persistence_microsoft_365_exchange_management_role_assignment.toml +++ b/rules/integrations/o365/persistence_exchange_management_role_assignment.toml @@ -2,7 +2,7 @@ creation_date = "2020/11/20" integration = ["o365"] maturity = "production" -updated_date = "2025/09/30" +updated_date = "2025/10/01" [rule] author = ["Elastic"] @@ -20,13 +20,13 @@ from = "now-9m" index = ["logs-o365.audit-*", "filebeat-*"] language = "kuery" license = "Elastic License v2" -name = "Microsoft 365 Exchange Management Group Role Assignment" +name = "M365 Exchange Management Group Role Assigned" 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 Microsoft 365 Exchange Management Group Role Assignment +### Investigating M365 Exchange Management Group Role Assigned Microsoft 365 Exchange Management roles define permissions for managing Exchange environments. Adversaries may exploit this by assigning roles to unauthorized users, ensuring persistent access. The detection rule monitors successful role assignments within Exchange, flagging potential unauthorized changes that align with persistence tactics, thus aiding in identifying and mitigating unauthorized access attempts. diff --git a/rules/integrations/o365/persistence_exchange_suspicious_mailbox_permission_delegation.toml b/rules/integrations/o365/persistence_exchange_suspicious_mailbox_permission_delegation.toml index 910bb0a982a..7e6472211e1 100644 --- a/rules/integrations/o365/persistence_exchange_suspicious_mailbox_permission_delegation.toml +++ b/rules/integrations/o365/persistence_exchange_suspicious_mailbox_permission_delegation.toml @@ -2,7 +2,7 @@ creation_date = "2021/05/17" integration = ["o365"] maturity = "production" -updated_date = "2025/05/07" +updated_date = "2025/10/01" [rule] author = ["Elastic", "Austin Songer"] @@ -18,10 +18,10 @@ false_positives = [ index = ["filebeat-*", "logs-o365.audit-*"] language = "kuery" license = "Elastic License v2" -name = "Suspicious Mailbox Permission Delegation in Exchange Online" +name = "M365 Exchange Mailbox High-Risk Permission Delegated" note = """## Triage and Analysis -### Investigating Suspicious Mailbox Permission Delegation in Exchange Online +### Investigating M365 Exchange Mailbox High-Risk Permission Delegated This rule detects the delegation of mailbox permissions in Microsoft 365 Exchange. This behavior may indicate that an adversary is attempting to gain access to another user's mailbox or send messages on behalf of that user. diff --git a/rules/integrations/o365/persistence_microsoft_365_teams_guest_access_enabled.toml b/rules/integrations/o365/persistence_teams_guest_access_enabled.toml similarity index 97% rename from rules/integrations/o365/persistence_microsoft_365_teams_guest_access_enabled.toml rename to rules/integrations/o365/persistence_teams_guest_access_enabled.toml index 4e9942bee5e..853391540a5 100644 --- a/rules/integrations/o365/persistence_microsoft_365_teams_guest_access_enabled.toml +++ b/rules/integrations/o365/persistence_teams_guest_access_enabled.toml @@ -2,7 +2,7 @@ creation_date = "2020/11/20" integration = ["o365"] maturity = "production" -updated_date = "2025/09/26" +updated_date = "2025/10/01" [rule] author = ["Elastic"] @@ -20,13 +20,13 @@ from = "now-9m" index = ["logs-o365.audit-*", "filebeat-*"] language = "kuery" license = "Elastic License v2" -name = "Microsoft 365 Teams Guest Access Enabled" +name = "M365 Teams Guest Access Enabled" 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 Microsoft 365 Teams Guest Access Enabled +### Investigating M365 Teams Guest Access Enabled Microsoft Teams allows organizations to collaborate with external users through guest access, facilitating communication and teamwork. However, adversaries can exploit this feature to gain persistent access to sensitive environments by enabling guest access without authorization. The detection rule monitors audit logs for specific configurations that indicate guest access has been enabled, helping identify unauthorized changes and potential security breaches. diff --git a/rules/integrations/o365/privilege_escalation_new_or_modified_federation_domain.toml b/rules/integrations/o365/privilege_escalation_exchange_new_or_modified_federation_domain.toml similarity index 97% rename from rules/integrations/o365/privilege_escalation_new_or_modified_federation_domain.toml rename to rules/integrations/o365/privilege_escalation_exchange_new_or_modified_federation_domain.toml index d2b54ec81bc..8a641cc411b 100644 --- a/rules/integrations/o365/privilege_escalation_new_or_modified_federation_domain.toml +++ b/rules/integrations/o365/privilege_escalation_exchange_new_or_modified_federation_domain.toml @@ -2,7 +2,7 @@ creation_date = "2021/05/17" integration = ["o365"] maturity = "production" -updated_date = "2025/09/26" +updated_date = "2025/10/01" [rule] author = ["Austin Songer"] @@ -13,13 +13,13 @@ identity provider. index = ["logs-o365.audit-*", "filebeat-*"] language = "kuery" license = "Elastic License v2" -name = "New or Modified Federation Domain" +name = "M365 Exchange Federated Domain Created or Modified" 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 New or Modified Federation Domain +### Investigating M365 Exchange Federated Domain Created or Modified Federation domains enable trust between Office 365 and external identity providers, facilitating seamless authentication. Adversaries may exploit this by altering federation settings to redirect authentication flows, potentially gaining unauthorized access. The detection rule monitors specific actions like domain modifications, signaling potential privilege escalation attempts, and alerts analysts to investigate these changes.