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

nldcsc_elastic_rules/rules/integrations/azure/privilege_escalation_azure_kubernetes_rolebinding_created.toml

@@ -0,0 +1,111 @@
+[metadata]
+creation_date = "2021/10/18"
+integration = ["azure"]
+maturity = "production"
+updated_date = "2025/09/30"
+
+[rule]
+author = ["Austin Songer"]
+description = """
+Identifies the creation of role binding or cluster role bindings. You can assign these roles to Kubernetes subjects
+(users, groups, or service accounts) with role bindings and cluster role bindings. An adversary who has permissions to
+create bindings and cluster-bindings in the cluster can create a binding to the cluster-admin ClusterRole or to other
+high privileges roles.
+"""
+from = "now-9m"
+index = ["logs-azure.activitylogs-*", "filebeat-*"]
+language = "kuery"
+license = "Elastic License v2"
+name = "Azure 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
+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
+
+- Review the Azure activity logs to identify the user or service account associated with the role binding creation event. Focus on the `event.dataset` and `azure.activitylogs.operation_name` fields to confirm the specific operation.
+- Check the `event.outcome` field to ensure the operation was successful and not a failed attempt, which might indicate a misconfiguration or testing.
+- Investigate the permissions and roles assigned to the identified user or service account to determine if they have legitimate reasons to create role bindings or cluster role bindings.
+- Examine the context of the role binding creation, such as the time of the event and any related activities, to identify any unusual patterns or correlations with other suspicious activities.
+- Verify if the role binding grants elevated privileges, such as cluster-admin, and assess the potential impact on the cluster's security posture.
+- Cross-reference the event with any recent changes in the cluster's configuration or access policies to understand if the role binding creation aligns with authorized administrative actions.
+
+### False positive analysis
+
+- Routine administrative tasks may trigger alerts when legitimate users create role bindings for operational purposes. To manage this, identify and whitelist specific user accounts or service accounts that regularly perform these tasks.
+- Automated deployment tools or scripts that configure Kubernetes clusters might create role bindings as part of their normal operation. Exclude these tools by filtering out known service accounts or IP addresses associated with these automated processes.
+- Scheduled maintenance or updates to the Kubernetes environment can result in multiple role binding creation events. Establish a maintenance window and suppress alerts during this period to avoid unnecessary noise.
+- Development and testing environments often have frequent role binding changes. Consider creating separate monitoring rules with adjusted thresholds or risk scores for these environments to reduce false positives.
+- Collaboration with the DevOps team can help identify expected role binding changes, allowing for preemptive exclusion of these events from triggering alerts.
+
+### Response and remediation
+
+- Immediately revoke any newly created role bindings or cluster role bindings that are unauthorized or suspicious to prevent further privilege escalation.
+- Isolate the affected Kubernetes cluster from the network to prevent potential lateral movement or further exploitation by the adversary.
+- Conduct a thorough review of recent activity logs to identify any unauthorized access or changes made by the adversary, focusing on the time frame around the alert.
+- Reset credentials and access tokens for any compromised accounts or service accounts involved in the unauthorized role binding creation.
+- Escalate the incident to the security operations team for further investigation and to determine if additional clusters or resources are affected.
+- Implement additional monitoring and alerting for any future role binding or cluster role binding creation events to ensure rapid detection and response.
+- Review and tighten role-based access control (RBAC) policies to ensure that only necessary permissions are granted to users, groups, and service accounts, minimizing the risk of privilege escalation.
+
+## Setup
+
+The Azure Fleet integration, Filebeat module, or similarly structured data is required to be compatible with this rule."""
+references = [
+    "https://docs.microsoft.com/en-us/azure/role-based-access-control/resource-provider-operations#microsoftkubernetes",
+    "https://www.microsoft.com/security/blog/2020/04/02/attack-matrix-kubernetes/",
+]
+risk_score = 21
+rule_id = "1c966416-60c1-436b-bfd0-e002fddbfd89"
+severity = "low"
+tags = [
+    "Domain: Cloud",
+    "Data Source: Azure",
+    "Use Case: Identity and Access Audit",
+    "Tactic: Privilege Escalation",
+    "Resources: Investigation Guide",
+]
+timestamp_override = "event.ingested"
+type = "query"
+
+query = '''
+event.dataset:azure.activitylogs and azure.activitylogs.operation_name:
+	("MICROSOFT.KUBERNETES/CONNECTEDCLUSTERS/RBAC.AUTHORIZATION.K8S.IO/ROLEBINDINGS/WRITE" or
+	 "MICROSOFT.KUBERNETES/CONNECTEDCLUSTERS/RBAC.AUTHORIZATION.K8S.IO/CLUSTERROLEBINDINGS/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.technique.subtechnique]]
+id = "T1078.004"
+name = "Cloud Accounts"
+reference = "https://attack.mitre.org/techniques/T1078/004/"
+
+
+[rule.threat.tactic]
+id = "TA0004"
+name = "Privilege Escalation"
+reference = "https://attack.mitre.org/tactics/TA0004/"
+[[rule.threat]]
+framework = "MITRE ATT&CK"
+[[rule.threat.technique]]
+id = "T1098"
+name = "Account Manipulation"
+reference = "https://attack.mitre.org/techniques/T1098/"
+
+
+[rule.threat.tactic]
+id = "TA0003"
+name = "Persistence"
+reference = "https://attack.mitre.org/tactics/TA0003/"
+

nldcsc_elastic_rules/rules/integrations/azure/privilege_escalation_azure_rbac_administrator_roles_assigned.toml

@@ -0,0 +1,110 @@
+[metadata]
+creation_date = "2025/09/15"
+integration = ["azure"]
+maturity = "production"
+updated_date = "2025/09/15"
+
+[rule]
+author = ["Elastic"]
+description = """
+Identifies when a user is assigned a built-in administrator role in Azure RBAC (Role-Based Access Control). These roles provide significant privileges and can be abused by attackers for lateral movement, persistence, or privilege escalation. The privileged built-in administrator roles include Owner, Contributor, User Access Administrator, Azure File Sync Administrator, Reservations Administrator, and Role Based Access Control Administrator.
+"""
+from = "now-9m"
+index = ["filebeat-*", "logs-azure.activitylogs-*"]
+language = "kuery"
+license = "Elastic License v2"
+name = "Azure RBAC Built-In Administrator Roles Assigned"
+note = """## Triage and Analysis
+
+### Investigating Azure RBAC Built-In Administrator Roles Assigned
+
+This rule identifies when a user is assigned a built-in administrator role in Azure RBAC (Role-Based Access Control). These roles provide significant privileges and can be abused by attackers for lateral movement, persistence, or privilege escalation. The privileged built-in administrator roles include Owner, Contributor, User Access Administrator, Azure File Sync Administrator, Reservations Administrator, and Role Based Access Control Administrator. Assignment can be done via the Azure portal, Azure CLI, PowerShell, or through API calls. Monitoring these assignments helps detect potential unauthorized privilege escalations.
+
+#### Privileged Built-In Administrator Roles
+- Contributor: b24988ac-6180-42a0-ab88-20f7382dd24c
+- Owner: 8e3af657-a8ff-443c-a75c-2fe8c4bcb635
+- Azure File Sync Administrator: 92b92042-07d9-4307-87f7-36a593fc5850
+- Reservations Administrator: a8889054-8d42-49c9-bc1c-52486c10e7cd
+- Role Based Access Control Administrator: f58310d9-a9f6-439a-9e8d-f62e7b41a168
+- User Access Administrator: 18d7d88d-d35e-4fb5-a5c3-7773c20a72d9
+
+### Possible investigation steps
+
+- Identify the user who assigned the role and examine their recent activity for any suspicious actions.
+- Review the source IP address and location associated with the role assignment event to assess if it aligns with expected user behavior or if it indicates potential unauthorized access.
+- Check the history of role assignments for the user who was assigned the role to determine if this is a recurring pattern or a one-time event.
+    - Additionally, identify the lifetime of the targeted user account to determine if it is a newly created account or an existing one.
+- Determine if the user assigning the role historically has the necessary permissions to assign such roles and has done so in the past.
+- Investigate any recent changes or activities performed by the newly assigned administrator to identify any suspicious actions or configurations that may have been altered.
+- Correlate with other logs, such as Microsoft Entra ID sign-in logs, to identify any unusual access patterns or behaviors for the user.
+
+### False positive analysis
+
+- Legitimate administrators may assign built-in administrator roles during routine operations, maintenance or as required for onboarding new staff.
+- Review internal tickets, change logs, or admin activity dashboards for approved operations.
+
+### Response and remediation
+
+- If administrative assignment was not authorized:
+  - Immediately remove the built-in administrator role from the account.
+  - Disable or lock the account and begin credential rotation.
+  - Audit activity performed by the account after elevation, especially changes to role assignments and resource access.
+- If suspicious:
+  - Notify the user and confirm whether they performed the action.
+  - Check for any automation or scripts that could be exploiting unused elevated access paths.
+  - Review conditional access and PIM (Privileged Identity Management) configurations to limit elevation without approval.
+- Strengthen posture:
+  - Require MFA and approval for all privilege escalation actions.
+  - Consider enabling JIT (Just-in-Time) access with expiration.
+"""
+references = [
+    "https://learn.microsoft.com/en-us/azure/role-based-access-control/built-in-roles",
+    "https://orca.security/resources/research-pod/azure-identity-access-management-iam-active-directory-ad/",
+    "https://www.microsoft.com/en-us/security/blog/2025/08/27/storm-0501s-evolving-techniques-lead-to-cloud-based-ransomware/"
+]
+risk_score = 73
+rule_id = "1a1046f4-9257-11f0-9a42-f661ea17fbce"
+severity = "high"
+tags = [
+    "Domain: Cloud",
+    "Data Source: Azure",
+    "Data Source: Azure Activity Logs",
+    "Use Case: Identity and Access Audit",
+    "Tactic: Privilege Escalation",
+    "Resources: Investigation Guide",
+]
+timestamp_override = "event.ingested"
+type = "query"
+
+query = '''
+event.dataset: azure.activitylogs and
+    event.action: "MICROSOFT.AUTHORIZATION/ROLEASSIGNMENTS/WRITE" and
+    azure.activitylogs.properties.requestbody.properties.roleDefinitionId:
+    (
+      *18d7d88d-d35e-4fb5-a5c3-7773c20a72d9* or
+      *f58310d9-a9f6-439a-9e8d-f62e7b41a168* or
+      *b24988ac-6180-42a0-ab88-20f7382dd24c* or
+      *8e3af657-a8ff-443c-a75c-2fe8c4bcb635* or
+      *92b92042-07d9-4307-87f7-36a593fc5850* or
+      *a8889054-8d42-49c9-bc1c-52486c10e7cd*
+  )
+'''
+
+
+[[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.003"
+name = "Additional Cloud Roles"
+reference = "https://attack.mitre.org/techniques/T1098/003/"
+
+
+
+[rule.threat.tactic]
+id = "TA0004"
+name = "Privilege Escalation"
+reference = "https://attack.mitre.org/tactics/TA0004/"

nldcsc_elastic_rules/rules/integrations/azure/privilege_escalation_entra_id_elevate_to_user_administrator_access.toml

@@ -0,0 +1,116 @@
+[metadata]
+creation_date = "2025/05/22"
+integration = ["azure"]
+maturity = "production"
+updated_date = "2025/09/15"
+
+[rule]
+author = ["Elastic", "Austin Songer"]
+description = """
+Identifies when a user has elevated their access to User Access Administrator for their Azure Resources. The User Access
+Administrator role allows users to manage user access to Azure resources, including the ability to assign roles and
+permissions. Adversaries may target an Entra ID Global Administrator or other privileged role to elevate their access to
+User Access Administrator, which can lead to further privilege escalation and unauthorized access to sensitive
+resources. This is a New Terms rule that only signals if the user principal name has not been seen doing this activity
+in the last 14 days.
+"""
+from = "now-9m"
+index = ["filebeat-*", "logs-azure.auditlogs-*"]
+language = "kuery"
+license = "Elastic License v2"
+name = "Microsoft Entra ID Elevated Access to User Access Administrator"
+note = """## Triage and Analysis
+
+### Investigating Microsoft 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.
+
+### Possible investigation steps
+
+- Review the `azure.auditlogs.properties.initiated_by.user.userPrincipalName` field to identify the user who elevated access.
+- Check `source.ip` and associated `source.geo.*` fields to determine the origin of the action. Confirm whether the IP, ASN, and location are expected for this user.
+- Investigate the application ID from `azure.auditlogs.properties.additional_details.value` to determine which interface or method was used to elevate access.
+- Pivot to Azure `signinlogs` or Entra `auditlogs` to:
+  - Review recent login history for the user.
+  - Look for unusual sign-in patterns or MFA prompts.
+  - Determine whether the account has performed any other privilege-related operations.
+- Correlate with directory role assignments or role-based access control (RBAC) modifications to assess whether the elevated access was used to add roles or modify permissions.
+
+### False positive analysis
+
+- Legitimate admin actions may involve access elevation during maintenance, migration, or investigations.
+- Some IT departments may elevate access temporarily without leaving structured change records.
+- Review internal tickets, change logs, or admin activity dashboards for approved operations.
+
+### Response and remediation
+
+- If elevation was not authorized:
+  - Immediately remove the User Access Administrator role from the account.
+  - Disable or lock the account and begin credential rotation.
+  - Audit activity performed by the account after elevation, especially changes to role assignments and resource access.
+- If suspicious:
+  - Notify the user and confirm whether they performed the action.
+  - Check for any automation or scripts that could be exploiting unused elevated access paths.
+  - Review conditional access and PIM (Privileged Identity Management) configurations to limit elevation without approval.
+- Strengthen posture:
+  - Require MFA and approval for all privilege escalation actions.
+  - Consider enabling JIT (Just-in-Time) access with expiration.
+  - Add alerts for repeated or unusual use of `Microsoft.Authorization/elevateAccess/action`.
+
+"""
+references = [
+    "https://learn.microsoft.com/en-us/azure/role-based-access-control/elevate-access-global-admin?tabs=azure-portal%2Centra-audit-logs/",
+    "https://permiso.io/blog/azures-apex-permissions-elevate-access-the-logs-security-teams-overlook",
+    "https://www.microsoft.com/en-us/security/blog/2025/08/27/storm-0501s-evolving-techniques-lead-to-cloud-based-ransomware/"
+]
+risk_score = 73
+rule_id = "8d9c4128-372a-11f0-9d8f-f661ea17fbcd"
+severity = "high"
+tags = [
+    "Domain: Cloud",
+    "Domain: Identity",
+    "Data Source: Azure",
+    "Data Source: Microsoft Entra ID",
+    "Data Source: Microsoft Entra ID Audit Logs",
+    "Use Case: Identity and Access Audit",
+    "Tactic: Privilege Escalation",
+    "Resources: Investigation Guide",
+]
+timestamp_override = "event.ingested"
+type = "new_terms"
+
+query = '''
+event.dataset: azure.auditlogs
+    and (
+      azure.auditlogs.operation_name: "User has elevated their access to User Access Administrator for their Azure Resources" or
+      azure.auditlogs.properties.additional_details.value: "Microsoft.Authorization/elevateAccess/action"
+    ) and event.outcome: "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.003"
+name = "Additional Cloud Roles"
+reference = "https://attack.mitre.org/techniques/T1098/003/"
+
+
+
+[rule.threat.tactic]
+id = "TA0004"
+name = "Privilege Escalation"
+reference = "https://attack.mitre.org/tactics/TA0004/"
+
+[rule.new_terms]
+field = "new_terms_fields"
+value = ["azure.auditlogs.properties.initiated_by.user.userPrincipalName"]
+[[rule.new_terms.history_window_start]]
+field = "history_window_start"
+value = "now-7d"
+
+

nldcsc_elastic_rules/rules/integrations/azure_openai/azure_openai_denial_of_ml_service_detection.toml

@@ -0,0 +1,100 @@
+[metadata]
+creation_date = "2025/02/25"
+integration = ["azure_openai"]
+maturity = "production"
+updated_date = "2025/09/25"
+
+[rule]
+author = ["Elastic"]
+description = """
+Detects patterns indicative of Denial-of-Service (DoS) attacks on machine learning (ML) models, focusing on unusually
+high volume and frequency of requests or patterns of requests that are known to cause performance degradation or service
+disruption, such as large input sizes or rapid API calls.
+"""
+false_positives = ["Unexpected system errors", "Legitimate spikes in usage due to business processes"]
+from = "now-60m"
+interval = "10m"
+language = "esql"
+license = "Elastic License v2"
+name = "Potential Denial of Azure OpenAI ML Service"
+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 Potential Denial of Azure OpenAI ML Service
+
+Azure OpenAI ML services enable scalable deployment of machine learning models, crucial for AI-driven applications. Adversaries may exploit these services by overwhelming them with excessive or malformed requests, leading to service degradation or outages. The detection rule identifies such threats by monitoring for high-frequency, large-size requests, which are indicative of potential denial-of-service attacks.
+
+### Possible investigation steps
+
+- Review the logs for the specific time window identified by the target_time_window field to understand the context and volume of requests.
+- Identify the specific Azure resource involved using the azure.resource.name field to determine if the service is critical or sensitive.
+- Examine the cloud.account.id field to ascertain if the requests are originating from a known or trusted account, or if they are potentially malicious.
+- Analyze the request patterns, focusing on the avg_request_size and count fields, to determine if the requests are consistent with normal usage or indicative of a potential attack.
+- Check for any recent changes or updates to the Azure OpenAI ML service configuration or deployment that might have affected its performance or security posture.
+- Correlate the findings with other security logs or alerts to identify any related suspicious activities or broader attack patterns.
+
+### False positive analysis
+
+- High-volume legitimate usage patterns can trigger false positives, such as during scheduled batch processing or data analysis tasks. Users can mitigate this by setting exceptions for known time windows or specific resource names associated with these activities.
+- Large input sizes from legitimate applications, like those processing extensive datasets or complex queries, may be misidentified as threats. Users should identify and whitelist these applications by their resource names or account IDs.
+- Testing and development environments often generate high-frequency requests as part of load testing or performance tuning. Users can exclude these environments by filtering out specific resource names or account IDs associated with non-production activities.
+- Automated scripts or integrations that interact with the Azure OpenAI ML service at high frequencies for valid business processes might be flagged. Users should document and exclude these scripts by identifying their unique request patterns or resource identifiers.
+
+### Response and remediation
+
+- Immediately throttle or block the IP addresses or accounts responsible for the high-frequency, large-size requests to prevent further service degradation.
+- Notify the Azure OpenAI service administrators and relevant stakeholders about the detected potential denial-of-service attack for awareness and further action.
+- Review and adjust rate limiting and request size policies on the Azure OpenAI ML service to mitigate the impact of similar attacks in the future.
+- Conduct a post-incident analysis to identify any vulnerabilities or misconfigurations that allowed the attack to occur and address them promptly.
+- Escalate the incident to the security operations team for further investigation and to determine if the attack is part of a larger threat campaign.
+- Implement additional monitoring and alerting for unusual patterns of requests, focusing on high volume and frequency, to enhance early detection of similar threats.
+- Coordinate with the cloud provider's support team to ensure any necessary infrastructure adjustments or protections are in place to prevent recurrence.
+"""
+references = [
+    "https://genai.owasp.org/llmrisk/llm04-model-denial-of-service",
+    "https://atlas.mitre.org/techniques/AML.T0029",
+]
+risk_score = 47
+rule_id = "b0450411-46e5-46d2-9b35-8b5dd9ba763e"
+setup = """## Setup
+
+For more information on streaming events, see the Azure OpenAI documentation:
+
+https://learn.microsoft.com/en-us/azure/azure-monitor/essentials/stream-monitoring-data-event-hubs
+"""
+severity = "medium"
+tags = [
+    "Domain: LLM",
+    "Data Source: Azure OpenAI",
+    "Data Source: Azure Event Hubs",
+    "Use Case: Denial of Service",
+    "Mitre Atlas: T0029",
+    "Resources: Investigation Guide",
+]
+timestamp_override = "event.ingested"
+type = "esql"
+
+query = '''
+from logs-azure_openai.logs-*
+| eval
+    Esql.time_window_date_trunc = date_trunc(1 minutes, @timestamp)
+| where azure.open_ai.operation_name == "ChatCompletions_Create"
+| keep
+    azure.open_ai.properties.request_length,
+    azure.resource.name,
+    cloud.account.id,
+    Esql.time_window_date_trunc
+| stats
+    Esql.event_count = count(*),
+    Esql.azure_open_ai_properties_request_length_avg = avg(azure.open_ai.properties.request_length)
+  by
+    Esql.time_window_date_trunc,
+    azure.resource.name
+| where
+    Esql.event_count >= 10 and
+    Esql.azure_open_ai_properties_request_length_avg >= 5000
+| sort Esql.event_count desc
+'''
+

nldcsc_elastic_rules/rules/integrations/azure_openai/azure_openai_insecure_output_handling_detection.toml

@@ -0,0 +1,94 @@
+[metadata]
+creation_date = "2025/02/25"
+integration = ["azure_openai"]
+maturity = "production"
+updated_date = "2025/09/25"
+
+[rule]
+author = ["Elastic"]
+description = """
+Detects when Azure OpenAI requests result in zero response length, potentially indicating issues in output handling that
+might lead to security exploits such as data leaks or code execution. This can occur in cases where the API fails to
+handle outputs correctly under certain input conditions.
+"""
+false_positives = ["Queries that are designed to expect empty responses or benign system errors"]
+from = "now-60m"
+interval = "10m"
+language = "esql"
+license = "Elastic License v2"
+name = "Azure OpenAI Insecure Output Handling"
+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 OpenAI Insecure Output Handling
+
+Azure OpenAI integrates AI capabilities into applications, enabling natural language processing tasks. However, improper output handling can lead to vulnerabilities, such as data leaks or unauthorized code execution. Adversaries might exploit these by crafting inputs that cause the API to mishandle responses. The detection rule identifies anomalies by flagging instances where API responses are unexpectedly empty, suggesting potential misuse or misconfiguration, especially when such events occur frequently.
+
+### Possible investigation steps
+
+- Review the logs for the specific Azure resource name flagged in the alert to understand the context and frequency of zero-length responses.
+- Examine the request lengths associated with the zero-length responses to identify any patterns or anomalies in the input data that might be causing the issue.
+- Check the cloud account ID associated with the alert to determine if there are any known issues or recent changes in configuration that could affect output handling.
+- Investigate the operation name "ChatCompletions_Create" to ensure that the API is being used as intended and that there are no unauthorized or unexpected uses.
+- Assess the overall environment for any recent updates or changes in the Azure OpenAI configuration that might have impacted output handling.
+
+### False positive analysis
+
+- Frequent legitimate requests with zero response length can occur during testing or development phases. To manage this, exclude known test environments or accounts from the detection rule by adding exceptions for specific cloud.account.id or azure.resource.name values.
+- Some applications may intentionally send requests that do not require a response, resulting in zero response length. Identify these applications and adjust the rule to exclude their specific azure.resource.name.
+- Network issues or temporary service disruptions can lead to zero-length responses. Monitor for patterns of such occurrences and consider excluding specific time frames or network segments if they are known to cause false positives.
+- Automated scripts or bots that interact with the API might generate zero-length responses as part of their normal operation. Identify these scripts and exclude their associated identifiers from the rule to prevent false alerts.
+
+### Response and remediation
+
+- Immediately isolate the affected Azure OpenAI resource to prevent further exploitation. This can be done by temporarily disabling the API or restricting access to it.
+- Review and validate the input handling mechanisms of the affected API to ensure they are robust against malformed or malicious inputs that could lead to insecure output handling.
+- Conduct a thorough audit of recent API requests and responses to identify any unauthorized access or data leaks. Pay special attention to requests with zero response length.
+- Implement additional logging and monitoring for the affected API to capture detailed information about requests and responses, which can help in identifying patterns or repeated attempts of exploitation.
+- Notify the security team and relevant stakeholders about the incident, providing them with detailed findings and any potential impact on data security.
+- If unauthorized access or data leakage is confirmed, follow the organization's incident response plan to notify affected parties and comply with any regulatory requirements.
+- Enhance detection capabilities by integrating anomaly detection tools that can identify unusual patterns in API usage, such as frequent zero-length responses, to prevent similar threats in the future.
+"""
+references = ["https://genai.owasp.org/llmrisk/llm02-insecure-output-handling"]
+risk_score = 21
+rule_id = "fb16f9ef-cb03-4234-adc2-44641f3b71ee"
+setup = """## Setup
+
+For more information on streaming events, see the Azure OpenAI documentation:
+
+https://learn.microsoft.com/en-us/azure/azure-monitor/essentials/stream-monitoring-data-event-hubs
+"""
+severity = "low"
+tags = [
+    "Domain: LLM",
+    "Data Source: Azure OpenAI",
+    "Data Source: Azure Event Hubs",
+    "Use Case: Insecure Output Handling",
+    "Resources: Investigation Guide",
+]
+timestamp_override = "event.ingested"
+type = "esql"
+
+query = '''
+from logs-azure_openai.logs-*
+| where
+    azure.open_ai.properties.response_length == 0 and
+    azure.open_ai.result_signature == "200" and
+    azure.open_ai.operation_name == "ChatCompletions_Create"
+| keep
+    azure.open_ai.properties.request_length,
+    azure.open_ai.result_signature,
+    cloud.account.id,
+    azure.resource.name
+| stats
+    Esql.event_count = count(*)
+  by
+    azure.resource.name
+| where
+    Esql.event_count >= 10
+| sort
+    Esql.event_count desc
+'''
+

nldcsc_elastic_rules/rules/integrations/azure_openai/azure_openai_model_theft_detection.toml

@@ -0,0 +1,100 @@
+[metadata]
+creation_date = "2025/02/25"
+integration = ["azure_openai"]
+maturity = "production"
+updated_date = "2025/09/25"
+
+[rule]
+author = ["Elastic"]
+description = """
+Monitors for suspicious activities that may indicate theft or unauthorized duplication of machine learning (ML) models,
+such as unauthorized API calls, atypical access patterns, or large data transfers that are unusual during model
+interactions.
+"""
+false_positives = ["Authorized model training", "Legitimate high volume data exchanges during scheduled updates"]
+from = "now-60m"
+interval = "10m"
+language = "esql"
+license = "Elastic License v2"
+name = "Potential Azure OpenAI Model Theft"
+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 Potential Azure OpenAI Model Theft
+
+Azure OpenAI models are integral to many applications, providing advanced machine learning capabilities. Adversaries may exploit these models by making unauthorized API calls or transferring large volumes of data, potentially indicating model theft. The detection rule identifies such threats by monitoring audit logs for unusual access patterns or excessive data transfers, flagging activities that deviate from normal usage.
+
+### Possible investigation steps
+
+- Review the audit logs for the specific resource group and resource name flagged in the alert to understand the context of the access patterns.
+- Analyze the timestamps associated with the suspicious activities to determine if they align with known operational periods or if they occur during unusual times.
+- Investigate the source of the API calls by identifying the IP addresses or user accounts involved in the "ListKey" operations to determine if they are authorized or known entities.
+- Examine the response length data to assess whether the volume of data transferred is consistent with legitimate use cases or if it suggests potential data exfiltration.
+- Cross-reference the flagged activities with other security logs or alerts to identify any correlated suspicious behavior or potential indicators of compromise.
+
+### False positive analysis
+
+- High-frequency legitimate API calls from automated scripts or applications may trigger the rule. Users can create exceptions for known scripts by identifying their specific access patterns and excluding them from the rule.
+- Large data transfers during scheduled model updates or backups can be mistaken for suspicious activity. Users should whitelist these operations by correlating them with scheduled maintenance windows or known update events.
+- Regular access by trusted internal teams for model evaluation or testing might appear as atypical patterns. Users can mitigate this by maintaining a list of authorized personnel and their expected access behaviors, then excluding these from the alert criteria.
+- Integration with other Azure services that require frequent access to OpenAI models could generate false positives. Users should document these integrations and adjust the rule to recognize and exclude these legitimate interactions.
+
+### Response and remediation
+
+- Immediately isolate the affected Azure resources by restricting network access to prevent further unauthorized API calls or data transfers.
+- Revoke and regenerate API keys associated with the compromised Azure OpenAI resources to prevent further unauthorized access.
+- Conduct a thorough review of audit logs to identify any additional unauthorized access attempts or data transfers, and document all findings for further analysis.
+- Notify the security operations team and relevant stakeholders about the potential model theft incident to ensure coordinated response efforts.
+- Implement additional monitoring on the affected resources to detect any further suspicious activities, focusing on access patterns and data transfer volumes.
+- Escalate the incident to the organization's incident response team for a comprehensive investigation and to determine if any data exfiltration occurred.
+- Review and update access controls and permissions for Azure OpenAI resources to ensure they adhere to the principle of least privilege, reducing the risk of future unauthorized access.
+"""
+references = ["https://genai.owasp.org/llmrisk/llm10-model-theft", "https://atlas.mitre.org/techniques/AML.T0044"]
+risk_score = 47
+rule_id = "4021e78d-5293-48d3-adee-a70fa4c18fab"
+setup = """## Setup
+
+For more information on
+streaming events, see the Azure OpenAI documentation:
+
+https://learn.microsoft.com/en-us/azure/azure-monitor/essentials/stream-monitoring-data-event-hubs
+"""
+severity = "medium"
+tags = [
+    "Domain: LLM",
+    "Data Source: Azure OpenAI",
+    "Data Source: Azure Event Hubs",
+    "Use Case: Model Theft",
+    "Mitre Atlas: T0044",
+    "Resources: Investigation Guide",
+]
+timestamp_override = "event.ingested"
+type = "esql"
+
+query = '''
+from logs-azure_openai.logs-*
+| where
+    azure.open_ai.operation_name == "ListKey" and
+    azure.open_ai.category == "Audit"
+| keep
+    @timestamp,
+    azure.open_ai.operation_name,
+    azure.open_ai.category,
+    azure.resource.group,
+    azure.resource.name,
+    azure.open_ai.properties.response_length
+| stats
+    Esql.event_count = count(*),
+    Esql.azure_open_ai_properties_response_length_max = max(azure.open_ai.properties.response_length)
+  by
+    azure.resource.group,
+    azure.resource.name
+| where
+    Esql.event_count >= 100 or
+    Esql.azure_open_ai_properties_response_length_max >= 1000000
+| sort
+    Esql.event_count desc
+'''
+