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

nldcsc_elastic_rules/rules/integrations/azure/initial_access_first_time_seen_device_code_auth.toml

@@ -0,0 +1,140 @@
+[metadata]
+creation_date = "2024/10/14"
+integration = ["azure"]
+maturity = "production"
+updated_date = "2025/09/26"
+
+[rule]
+author = ["Elastic", "Matteo Potito Giorgio"]
+description = """
+Identifies when a user is observed for the first time in the last 14 days authenticating using the device code
+authentication workflow. This authentication workflow can be abused by attackers to phish users and steal access tokens
+to impersonate the victim. By its very nature, device code should only be used when logging in to devices without
+keyboards, where it is difficult to enter emails and passwords.
+"""
+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"
+note = """## Triage and analysis
+
+### Investigating First Occurrence of Entra ID Auth via DeviceCode Protocol
+
+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.
+
+### Possible Investigation Steps
+
+#### Identify the User and Authentication Details
+- **User Principal Name (UPN)**: Review `azure.signinlogs.properties.user_principal_name` to identify the user involved in the authentication event.
+- **User ID**: Check `azure.signinlogs.properties.user_id` for a unique identifier of the affected account.
+- **Authentication Protocol**: Confirm that `azure.signinlogs.properties.authentication_protocol` is set to `deviceCode`.
+- **Application Used**: Verify the application through `azure.signinlogs.properties.app_display_name` and `azure.signinlogs.properties.app_id` to determine if it is an expected application.
+
+#### Review the Source IP and Geolocation
+- **Source IP Address**: Check `source.ip` and compare it with previous authentication logs to determine whether the login originated from a trusted or expected location.
+- **Geolocation Details**: Analyze `source.geo.city_name`, `source.geo.region_name`, and `source.geo.country_name` to confirm whether the login location is suspicious.
+- **ASN / ISP Details**: Review `source.as.organization.name` to check if the IP is associated with a known organization or cloud provider.
+
+#### Examine Multi-Factor Authentication (MFA) and Conditional Access
+- **MFA Enforcement**: Review `azure.signinlogs.properties.applied_conditional_access_policies` to determine if MFA was enforced during the authentication.
+- **Conditional Access Policies**: Check `azure.signinlogs.properties.conditional_access_status` to understand if conditional access policies were applied and if any controls were bypassed.
+- **Authentication Method**: Look at `azure.signinlogs.properties.authentication_details` to confirm how authentication was satisfied (e.g., MFA via claim in token).
+
+#### Validate Device and Client Details
+- **Device Information**: Review `azure.signinlogs.properties.device_detail.browser` to determine if the login aligns with the expected behavior of a device that lacks a keyboard.
+- **User-Agent Analysis**: Inspect `user_agent.original` for anomalies, such as an unexpected operating system or browser.
+- **Client Application**: Verify `azure.signinlogs.properties.client_app_used` to confirm whether the login was performed using a known client.
+
+#### Investigate Related Activities
+- **Correlate with Phishing Attempts**: Check if the user recently reported phishing attempts or suspicious emails.
+- **Monitor for Anomalous Account Activity**: Look for recent changes in the user's account settings, including password resets, role changes, or delegation of access.
+- **Check for Additional DeviceCode Logins**: Review if other users in the environment have triggered similar authentication events within the same timeframe.
+
+## False Positive Analysis
+
+- **Legitimate Device Enrollment**: If the user is setting up a new device (e.g., a smart TV or kiosk), this authentication may be expected.
+- **Automation or Scripting**: Some legitimate applications or scripts may leverage the `DeviceCode` authentication protocol for non-interactive logins.
+- **Shared Devices in Organizations**: In cases where shared workstations or conference room devices are in use, legitimate users may trigger alerts.
+- **Travel and Remote Work**: If the user is traveling or accessing from a new location, confirm legitimacy before taking action.
+
+## Response and Remediation
+
+- **Revoke Suspicious Access Tokens**: Immediately revoke any access tokens associated with this authentication event.
+- **Investigate the User’s Recent Activity**: Review additional authentication logs, application access, and recent permission changes for signs of compromise.
+- **Reset Credentials and Enforce Stronger Authentication**:
+  - Reset the affected user’s credentials.
+  - Enforce stricter MFA policies for sensitive accounts.
+  - Restrict `DeviceCode` authentication to only required applications.
+- **Monitor for Further Anomalies**:
+  - Enable additional logging and anomaly detection for DeviceCode logins.
+  - Set up alerts for unauthorized access attempts using this authentication method.
+- **Educate Users on Phishing Risks**: If phishing is suspected, notify the affected user and provide security awareness training on how to recognize and report phishing attempts.
+- **Review and Adjust Conditional Access Policies**:
+  - Limit `DeviceCode` authentication to approved users and applications.
+  - Implement stricter geolocation-based authentication restrictions.
+"""
+references = [
+    "https://aadinternals.com/post/phishing/",
+    "https://www.blackhillsinfosec.com/dynamic-device-code-phishing/",
+    "https://www.volexity.com/blog/2025/02/13/multiple-russian-threat-actors-targeting-microsoft-device-code-authentication/",
+    "https://learn.microsoft.com/en-us/entra/identity/conditional-access/concept-authentication-flows",
+]
+risk_score = 47
+rule_id = "af22d970-7106-45b4-b5e3-460d15333727"
+setup = "This rule optionally requires Azure Sign-In logs from the Azure integration. Ensure that the Azure integration is correctly set up and that the required data is being collected.\n"
+severity = "medium"
+tags = [
+    "Domain: Cloud",
+    "Data Source: Azure",
+    "Data Source: Microsoft Entra ID",
+    "Use Case: Identity and Access Audit",
+    "Tactic: Initial Access",
+    "Resources: Investigation Guide",
+]
+timestamp_override = "event.ingested"
+type = "new_terms"
+
+query = '''
+event.dataset:(azure.activitylogs or azure.signinlogs)
+    and (
+            azure.signinlogs.properties.authentication_protocol:deviceCode or
+            azure.signinlogs.properties.original_transfer_method: "Device code flow" or
+            azure.activitylogs.properties.authentication_protocol:deviceCode
+        )
+    and event.outcome:success
+'''
+
+
+[[rule.threat]]
+framework = "MITRE ATT&CK"
+[[rule.threat.technique]]
+id = "T1566"
+name = "Phishing"
+reference = "https://attack.mitre.org/techniques/T1566/"
+[[rule.threat.technique.subtechnique]]
+id = "T1566.002"
+name = "Spearphishing Link"
+reference = "https://attack.mitre.org/techniques/T1566/002/"
+
+[[rule.threat.technique]]
+id = "T1078"
+name = "Valid Accounts"
+reference = "https://attack.mitre.org/techniques/T1078/"
+[[rule.threat.technique.subtechnique]]
+id = "T1078.004"
+name = "Cloud Accounts"
+reference = "https://attack.mitre.org/techniques/T1078/004/"
+
+
+[rule.threat.tactic]
+id = "TA0001"
+name = "Initial Access"
+reference = "https://attack.mitre.org/tactics/TA0001/"
+
+[rule.new_terms]
+field = "new_terms_fields"
+value = ["azure.signinlogs.properties.user_principal_name"]
+[[rule.new_terms.history_window_start]]
+field = "history_window_start"
+value = "now-14d"

nldcsc_elastic_rules/rules/integrations/azure/initial_access_graph_first_occurrence_of_client_request.toml

@@ -0,0 +1,143 @@
+[metadata]
+creation_date = "2025/04/23"
+integration = ["azure"]
+maturity = "production"
+updated_date = "2025/09/26"
+
+[rule]
+author = ["Elastic"]
+description = """
+This New Terms rule focuses on the first occurrence of a client application ID
+(azure.graphactivitylogs.properties.app_id) making a request to Microsoft Graph API for a specific tenant ID
+(azure.tenant_id) and user principal object ID (azure.graphactivitylogs.properties.user_principal_object_id). This rule
+may helps identify unauthorized access or actions performed by compromised accounts. Advesaries may succesfully
+compromise a user's credentials and use the Microsoft Graph API to access resources or perform actions on behalf of the
+user.
+"""
+false_positives = [
+    """
+    Users legitimately accessing Microsoft Graph API using the specified client application ID and tenant ID. This may
+    include authorized applications or services that interact with Microsoft Graph on behalf of users.
+    """,
+    """
+    Authorized third-party applications or services that use the specified client application ID to access Microsoft
+    Graph API resources for legitimate purposes.
+    """,
+    """
+    Administrative or automated tasks that involve accessing Microsoft Graph API using the specified client application
+    ID and tenant ID, such as provisioning or managing resources.
+    """,
+]
+from = "now-9m"
+index = ["logs-azure.graphactivitylogs-*"]
+language = "kuery"
+license = "Elastic License v2"
+name = "Microsoft Graph First Occurrence of Client Request"
+note = """## Triage and analysis
+
+### Investigating Microsoft Graph First Occurrence of Client Request
+
+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.
+
+Adversaries frequently exploit legitimate Microsoft or third-party application IDs to avoid raising suspicion during initial access. By using pre-consented or trusted apps to interact with Microsoft Graph, attackers can perform actions on behalf of users without triggering conventional authentication alerts or requiring additional user interaction.
+
+### Possible investigation steps
+
+- Review `azure.graphactivitylogs.properties.user_principal_object_id` and correlate with recent sign-in logs for the associated user.
+- Determine whether `azure.graphactivitylogs.properties.app_id` is a known and approved application in your environment.
+- Investigate the `user_agent.original` field for signs of scripted access (e.g., automation tools or libraries).
+- Check the source IP address (`source.ip`) and geolocation data (`source.geo.*`) for unfamiliar origins.
+- Inspect `azure.graphactivitylogs.properties.scopes` to understand the level of access being requested by the app.
+- Examine any follow-up Graph API activity from the same `app_id` or `user_principal_object_id` for signs of data access or exfiltration.
+- Correlate with device or session ID fields (`azure.graphactivitylogs.properties.c_sid`, if present) to detect persistent or repeat activity.
+
+### False positive analysis
+
+- First-time use of a legitimate Microsoft or enterprise-approved application.
+- Developer or automation workflows initiating new Graph API requests.
+- Valid end-user activity following device reconfiguration or new client installation.
+- Maintain an allowlist of expected `app_id` values and known developer tools.
+- Suppress detections from known good `user_agent.original` strings or approved source IP ranges.
+- Use device and identity telemetry to distinguish trusted vs. unknown activity sources.
+- Combine with session risk or sign-in anomaly signals where available.
+
+### Response and remediation
+
+- Reach out to the user and verify whether they authorized the application access.
+- Revoke active OAuth tokens and reset credentials if unauthorized use is confirmed.
+- Search for additional Graph API calls made by the same `app_id` or `user_principal_object_id`.
+- Investigate whether sensitive resources (mail, files, Teams, contacts) were accessed.
+- Apply Conditional Access policies to limit Graph API access by app type, IP, or device state.
+- Restrict user consent for third-party apps and enforce admin approval workflows.
+- Monitor usage of new or uncommon `app_id` values across your tenant.
+- Provide user education on OAuth phishing tactics and reporting suspicious prompts.
+"""
+references = [
+    "https://www.volexity.com/blog/2025/04/22/phishing-for-codes-russian-threat-actors-target-microsoft-365-oauth-workflows/",
+]
+risk_score = 21
+rule_id = "2a3f38a8-204e-11f0-9c1f-f661ea17fbcd"
+severity = "low"
+tags = [
+    "Domain: Cloud",
+    "Data Source: Azure",
+    "Data Source: Microsoft Graph",
+    "Data Source: Microsoft Graph Activity Logs",
+    "Resources: Investigation Guide",
+    "Use Case: Identity and Access Audit",
+    "Tactic: Initial Access",
+]
+timestamp_override = "event.ingested"
+type = "new_terms"
+
+query = '''
+event.dataset: "azure.graphactivitylogs"
+    and event.type: "access"
+    and azure.graphactivitylogs.properties.c_idtyp: "user"
+    and azure.graphactivitylogs.properties.client_auth_method: 0
+    and http.response.status_code: 200
+    and url.domain: "graph.microsoft.com"
+'''
+
+
+[[rule.threat]]
+framework = "MITRE ATT&CK"
+[[rule.threat.technique]]
+id = "T1078"
+name = "Valid Accounts"
+reference = "https://attack.mitre.org/techniques/T1078/"
+[[rule.threat.technique.subtechnique]]
+id = "T1078.004"
+name = "Cloud Accounts"
+reference = "https://attack.mitre.org/techniques/T1078/004/"
+
+
+
+[rule.threat.tactic]
+id = "TA0001"
+name = "Initial Access"
+reference = "https://attack.mitre.org/tactics/TA0001/"
+[[rule.threat]]
+framework = "MITRE ATT&CK"
+[[rule.threat.technique]]
+id = "T1528"
+name = "Steal Application Access Token"
+reference = "https://attack.mitre.org/techniques/T1528/"
+
+
+[rule.threat.tactic]
+id = "TA0006"
+name = "Credential Access"
+reference = "https://attack.mitre.org/tactics/TA0006/"
+
+[rule.new_terms]
+field = "new_terms_fields"
+value = [
+    "azure.graphactivitylogs.properties.app_id",
+    "azure.graphactivitylogs.properties.user_principal_object_id"
+]
+[[rule.new_terms.history_window_start]]
+field = "history_window_start"
+value = "now-14d"
+
+

nldcsc_elastic_rules/rules/integrations/azure/persistence_azure_application_credential_modification.toml

@@ -0,0 +1,104 @@
+[metadata]
+creation_date = "2020/12/14"
+integration = ["azure"]
+maturity = "production"
+updated_date = "2025/09/30"
+
+[rule]
+author = ["Elastic"]
+description = """
+Identifies when a new credential is added to an application in Azure. An application may use a certificate or secret
+string to prove its identity when requesting a token. Multiple certificates and secrets can be added for an application
+and an adversary may abuse this by creating an additional authentication method to evade defenses or persist in an
+environment.
+"""
+false_positives = [
+    """
+    Application credential additions may be done by a system or network administrator. Verify whether the username,
+    hostname, and/or resource name should be making changes in your environment. Application credential additions from
+    unfamiliar users or hosts should be investigated. If known behavior is causing false positives, it can be exempted
+    from the rule.
+    """,
+]
+from = "now-9m"
+index = ["logs-azure.auditlogs-*", "filebeat-*"]
+language = "kuery"
+license = "Elastic License v2"
+name = "Azure Application Credential 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 Azure Application Credential Modification
+
+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.
+
+### Possible investigation steps
+
+- Review the Azure audit logs to identify the specific application that had its credentials updated, focusing on entries with the operation name "Update application - Certificates and secrets management" and a successful outcome.
+- Determine the identity of the user or service principal that performed the credential modification by examining the associated user or principal ID in the audit log entry.
+- Investigate the context of the credential modification by checking for any recent changes or unusual activities related to the application, such as modifications to permissions or roles.
+- Assess the legitimacy of the new credential by verifying if it aligns with expected operational procedures or if it was authorized by a known and trusted entity.
+- Check for any additional suspicious activities in the audit logs around the same timeframe, such as failed login attempts or other modifications to the application, to identify potential indicators of compromise.
+- Contact the application owner or relevant stakeholders to confirm whether the credential addition was expected and authorized, and gather any additional context or concerns they might have.
+
+### False positive analysis
+
+- Routine credential updates by authorized personnel can trigger alerts. Regularly review and document credential management activities to distinguish between legitimate and suspicious actions.
+- Automated processes or scripts that update application credentials as part of maintenance or deployment cycles may cause false positives. Identify and whitelist these processes to prevent unnecessary alerts.
+- Credential updates during application scaling or migration might be flagged. Coordinate with IT teams to schedule these activities and temporarily adjust monitoring thresholds or exclusions.
+- Third-party integrations that require periodic credential updates can be mistaken for unauthorized changes. Maintain an inventory of such integrations and establish baseline behaviors to filter out benign activities.
+- Frequent updates by specific service accounts could be part of normal operations. Monitor these accounts separately and consider creating exceptions for known, non-threatening patterns.
+
+### Response and remediation
+
+- Immediately revoke the unauthorized credentials by accessing the Azure portal and removing any suspicious certificates or secret strings associated with the affected application.
+- Conduct a thorough review of the application's access logs to identify any unauthorized access or actions performed using the compromised credentials.
+- Reset and update all legitimate credentials for the affected application to ensure no further unauthorized access can occur.
+- Notify the security team and relevant stakeholders about the incident, providing details of the unauthorized credential modification and any potential impact.
+- Implement additional monitoring on the affected application to detect any further unauthorized changes or access attempts.
+- Review and tighten access controls and permissions for managing application credentials to prevent unauthorized modifications in the future.
+- If necessary, escalate the incident to higher-level security management or external cybersecurity experts for further investigation and response.
+
+## Setup
+
+The Azure Fleet integration, Filebeat module, or similarly structured data is required to be compatible with this rule."""
+references = [
+    "https://msrc-blog.microsoft.com/2020/12/13/customer-guidance-on-recent-nation-state-cyber-attacks/",
+]
+risk_score = 47
+rule_id = "1a36cace-11a7-43a8-9a10-b497c5a02cd3"
+severity = "medium"
+tags = [
+    "Domain: Cloud",
+    "Data Source: Azure",
+    "Use Case: Identity and Access Audit",
+    "Tactic: Persistence",
+    "Resources: Investigation Guide",
+]
+timestamp_override = "event.ingested"
+type = "query"
+
+query = '''
+event.dataset:azure.auditlogs and azure.auditlogs.operation_name:"Update application - Certificates and secrets management" and event.outcome:(success or Success)
+'''
+
+
+[[rule.threat]]
+framework = "MITRE ATT&CK"
+[[rule.threat.technique]]
+id = "T1098"
+name = "Account Manipulation"
+reference = "https://attack.mitre.org/techniques/T1098/"
+[[rule.threat.technique.subtechnique]]
+id = "T1098.001"
+name = "Additional Cloud Credentials"
+reference = "https://attack.mitre.org/techniques/T1098/001/"
+
+
+
+[rule.threat.tactic]
+id = "TA0003"
+name = "Persistence"
+reference = "https://attack.mitre.org/tactics/TA0003/"

nldcsc_elastic_rules/rules/integrations/azure/persistence_azure_automation_account_created.toml

@@ -0,0 +1,98 @@
+[metadata]
+creation_date = "2020/08/18"
+integration = ["azure"]
+maturity = "production"
+updated_date = "2025/09/26"
+
+[rule]
+author = ["Elastic"]
+description = """
+Identifies when an Azure Automation account is created. Azure Automation accounts can be used to automate management
+tasks and orchestrate actions across systems. An adversary may create an Automation account in order to maintain
+persistence in their target's environment.
+"""
+from = "now-9m"
+index = ["logs-azure.activitylogs-*", "filebeat-*"]
+language = "kuery"
+license = "Elastic License v2"
+name = "Azure Automation Account 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 Automation Account Created
+
+Azure Automation accounts facilitate the automation of management tasks and orchestration across cloud environments, enhancing operational efficiency. However, adversaries may exploit these accounts to establish persistence by automating malicious activities. The detection rule monitors the creation of these accounts by analyzing specific Azure activity logs, focusing on successful operations, to identify potential unauthorized or suspicious account creations.
+
+### Possible investigation steps
+
+- Review the Azure activity logs to confirm the creation of the Automation account by checking for the operation name "MICROSOFT.AUTOMATION/AUTOMATIONACCOUNTS/WRITE" and ensure the event outcome is marked as Success.
+- Identify the user or service principal that initiated the creation of the Automation account by examining the associated user identity information in the activity logs.
+- Investigate the context of the Automation account creation by reviewing recent activities performed by the identified user or service principal to determine if there are any other suspicious or unauthorized actions.
+- Check the configuration and permissions of the newly created Automation account to ensure it does not have excessive privileges that could be exploited for persistence or lateral movement.
+- Correlate the Automation account creation event with other security alerts or logs to identify any patterns or indicators of compromise that may suggest malicious intent.
+
+### False positive analysis
+
+- Routine administrative tasks may trigger the rule when legitimate users create Azure Automation accounts for operational purposes. To manage this, maintain a list of authorized personnel and their expected activities, and cross-reference alerts with this list.
+- Automated deployment scripts or infrastructure-as-code tools might create automation accounts as part of their normal operation. Identify these scripts and exclude their associated activities from triggering alerts by using specific identifiers or tags.
+- Scheduled maintenance or updates by cloud service providers could result in the creation of automation accounts. Verify the timing and context of the account creation against known maintenance schedules and exclude these from alerts if they match.
+- Development and testing environments often involve frequent creation and deletion of resources, including automation accounts. Implement separate monitoring rules or environments for these non-production areas to reduce noise in alerts.
+
+### Response and remediation
+
+- Immediately review the Azure activity logs to confirm the creation of the Automation account and identify the user or service principal responsible for the action.
+- Disable the newly created Azure Automation account to prevent any potential malicious automation tasks from executing.
+- Conduct a thorough investigation of the user or service principal that created the account to determine if their credentials have been compromised or if they have acted maliciously.
+- Reset credentials and enforce multi-factor authentication for the identified user or service principal to prevent unauthorized access.
+- Review and adjust Azure role-based access control (RBAC) policies to ensure that only authorized personnel have the ability to create Automation accounts.
+- Escalate the incident to the security operations team for further analysis and to determine if additional systems or accounts have been compromised.
+- Implement enhanced monitoring and alerting for future Automation account creations to quickly detect and respond to similar threats.
+
+## Setup
+
+The Azure Fleet integration, Filebeat module, or similarly structured data is required to be compatible with this rule."""
+references = [
+    "https://powerzure.readthedocs.io/en/latest/Functions/operational.html#create-backdoor",
+    "https://github.com/hausec/PowerZure",
+    "https://posts.specterops.io/attacking-azure-azure-ad-and-introducing-powerzure-ca70b330511a",
+    "https://azure.microsoft.com/en-in/blog/azure-automation-runbook-management/",
+]
+risk_score = 21
+rule_id = "df26fd74-1baa-4479-b42e-48da84642330"
+severity = "low"
+tags = ["Domain: Cloud", "Data Source: Azure", "Use Case: Identity and Access Audit", "Tactic: Persistence", "Resources: Investigation Guide"]
+timestamp_override = "event.ingested"
+type = "query"
+
+query = '''
+event.dataset:azure.activitylogs and azure.activitylogs.operation_name:"MICROSOFT.AUTOMATION/AUTOMATIONACCOUNTS/WRITE" and event.outcome:(Success or success)
+'''
+
+
+[[rule.threat]]
+framework = "MITRE ATT&CK"
+[[rule.threat.technique]]
+id = "T1078"
+name = "Valid Accounts"
+reference = "https://attack.mitre.org/techniques/T1078/"
+
+
+[rule.threat.tactic]
+id = "TA0003"
+name = "Persistence"
+reference = "https://attack.mitre.org/tactics/TA0003/"
+[[rule.threat]]
+framework = "MITRE ATT&CK"
+[[rule.threat.technique]]
+id = "T1078"
+name = "Valid Accounts"
+reference = "https://attack.mitre.org/techniques/T1078/"
+
+
+[rule.threat.tactic]
+id = "TA0005"
+name = "Defense Evasion"
+reference = "https://attack.mitre.org/tactics/TA0005/"
+

nldcsc_elastic_rules/rules/integrations/azure/persistence_azure_automation_webhook_created.toml

@@ -0,0 +1,102 @@
+[metadata]
+creation_date = "2020/08/18"
+integration = ["azure"]
+maturity = "production"
+updated_date = "2025/09/30"
+
+[rule]
+author = ["Elastic"]
+description = """
+Identifies when an Azure Automation webhook is created. Azure Automation runbooks can be configured to execute via a
+webhook. A webhook uses a custom URL passed to Azure Automation along with a data payload specific to the runbook. An
+adversary may create a webhook in order to trigger a runbook that contains malicious code.
+"""
+from = "now-9m"
+index = ["logs-azure.activitylogs-*", "filebeat-*"]
+language = "kuery"
+license = "Elastic License v2"
+name = "Azure Automation Webhook 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 Automation Webhook Created
+
+Azure Automation webhooks enable automated task execution via HTTP requests, integrating with external systems. Adversaries may exploit this by creating webhooks to trigger runbooks with harmful scripts, maintaining persistence. The detection rule identifies webhook creation events, focusing on specific operation names and successful outcomes, to flag potential misuse in cloud environments.
+
+### Possible investigation steps
+
+- Review the Azure activity logs to identify the user or service principal that initiated the webhook creation by examining the `event.dataset` and `azure.activitylogs.operation_name` fields.
+- Check the associated runbook linked to the created webhook to determine its purpose and inspect its content for any potentially malicious scripts or commands.
+- Investigate the source IP address and location from which the webhook creation request originated to identify any unusual or unauthorized access patterns.
+- Verify the legitimacy of the webhook by contacting the owner of the Azure Automation account or the relevant team to confirm if the webhook creation was expected and authorized.
+- Assess the broader context of the activity by reviewing recent changes or activities in the Azure Automation account to identify any other suspicious actions or configurations.
+
+### False positive analysis
+
+- Routine webhook creations for legitimate automation tasks can trigger false positives. Review the context of the webhook creation, such as the associated runbook and its purpose, to determine if it aligns with expected operations.
+- Frequent webhook creations by trusted users or service accounts may not indicate malicious activity. Consider creating exceptions for these users or accounts to reduce noise in alerts.
+- Automated deployment processes that involve creating webhooks as part of their workflow can be mistaken for suspicious activity. Document these processes and exclude them from triggering alerts if they are verified as safe.
+- Integration with third-party services that require webhook creation might generate alerts. Verify these integrations and whitelist them if they are part of approved business operations.
+- Regularly review and update the list of exceptions to ensure that only verified non-threatening behaviors are excluded, maintaining the effectiveness of the detection rule.
+
+### Response and remediation
+
+- Immediately disable the suspicious webhook to prevent further execution of potentially harmful runbooks.
+- Review the runbook associated with the webhook for any unauthorized or malicious scripts and remove or quarantine any identified threats.
+- Conduct a thorough audit of recent changes in the Azure Automation account to identify any unauthorized access or modifications.
+- Revoke any compromised credentials and enforce multi-factor authentication (MFA) for all accounts with access to Azure Automation.
+- Notify the security team and relevant stakeholders about the incident for further investigation and to ensure awareness of potential threats.
+- Implement enhanced monitoring and alerting for webhook creation and execution activities to detect similar threats in the future.
+- Document the incident, including actions taken and lessons learned, to improve response strategies and prevent recurrence.
+
+## Setup
+
+The Azure Fleet integration, Filebeat module, or similarly structured data is required to be compatible with this rule."""
+references = [
+    "https://powerzure.readthedocs.io/en/latest/Functions/operational.html#create-backdoor",
+    "https://github.com/hausec/PowerZure",
+    "https://posts.specterops.io/attacking-azure-azure-ad-and-introducing-powerzure-ca70b330511a",
+    "https://www.ciraltos.com/webhooks-and-azure-automation-runbooks/",
+]
+risk_score = 21
+rule_id = "e9ff9c1c-fe36-4d0d-b3fd-9e0bf4853a62"
+severity = "low"
+tags = ["Domain: Cloud", "Data Source: Azure", "Use Case: Configuration Audit", "Tactic: Persistence", "Resources: Investigation Guide"]
+timestamp_override = "event.ingested"
+type = "query"
+
+query = '''
+event.dataset:azure.activitylogs and
+  azure.activitylogs.operation_name:
+    (
+      "MICROSOFT.AUTOMATION/AUTOMATIONACCOUNTS/WEBHOOKS/ACTION" or
+      "MICROSOFT.AUTOMATION/AUTOMATIONACCOUNTS/WEBHOOKS/WRITE"
+    ) and
+  event.outcome:(Success or success)
+'''
+
+[[rule.threat]]
+framework = "MITRE ATT&CK"
+[[rule.threat.technique]]
+id = "T1546"
+name = "Event Triggered Execution"
+reference = "https://attack.mitre.org/techniques/T1546/"
+
+[rule.threat.tactic]
+id = "TA0003"
+name = "Persistence"
+reference = "https://attack.mitre.org/tactics/TA0003/"
+
+[[rule.threat]]
+framework = "MITRE ATT&CK"
+[[rule.threat.technique]]
+id = "T1608"
+name = "Stage Capabilities"
+reference = "https://attack.mitre.org/techniques/T1608/"
+
+[rule.threat.tactic]
+id = "TA0042"
+name = "Resource Development"
+reference = "https://attack.mitre.org/tactics/TA0042/"