Add investigation guides

rules/integrations/azure_openai/azure_openai_denial_of_ml_service_detection.toml

@@ -1,7 +1,7 @@
 [metadata]
 creation_date = "2025/02/25"
 maturity = "production"
-updated_date = "2025/03/20"
+updated_date = "2025/04/07"
 
 [rule]
 author = ["Elastic"]
@@ -16,6 +16,41 @@ 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",
@@ -35,6 +70,7 @@ tags = [
     "Data Source: Azure Event Hubs",
     "Use Case: Denial of Service",
     "Mitre Atlas: T0029",
+    "Resources: Investigation Guide",
 ]
 timestamp_override = "event.ingested"
 type = "esql"

rules/integrations/azure_openai/azure_openai_insecure_output_handling_detection.toml

@@ -1,7 +1,7 @@
 [metadata]
 creation_date = "2025/02/25"
 maturity = "production"
-updated_date = "2025/03/20"
+updated_date = "2025/04/07"
 
 [rule]
 author = ["Elastic"]
@@ -16,6 +16,40 @@ 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"
@@ -31,6 +65,7 @@ tags = [
     "Data Source: Azure OpenAI",
     "Data Source: Azure Event Hubs",
     "Use Case: Insecure Output Handling",
+    "Resources: Investigation Guide",
 ]
 timestamp_override = "event.ingested"
 type = "esql"

rules/integrations/azure_openai/azure_openai_model_theft_detection.toml

@@ -1,7 +1,7 @@
 [metadata]
 creation_date = "2025/02/25"
 maturity = "production"
-updated_date = "2025/03/20"
+updated_date = "2025/04/07"
 
 [rule]
 author = ["Elastic"]
@@ -16,6 +16,40 @@ 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"
@@ -33,6 +67,7 @@ tags = [
     "Data Source: Azure Event Hubs",
     "Use Case: Model Theft",
     "Mitre Atlas: T0044",
+    "Resources: Investigation Guide",
 ]
 timestamp_override = "event.ingested"
 type = "esql"

rules/linux/command_and_control_frequent_egress_netcon_from_sus_executable.toml

@@ -2,7 +2,7 @@
 creation_date = "2025/02/20"
 integration = ["endpoint"]
 maturity = "production"
-updated_date = "2025/04/03"
+updated_date = "2025/04/07"
 
 [rule]
 author = ["Elastic"]
@@ -17,6 +17,42 @@ interval = "1h"
 language = "esql"
 license = "Elastic License v2"
 name = "High Number of Egress Network Connections from Unusual Executable"
+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 High Number of Egress Network Connections from Unusual Executable
+
+In Linux environments, executables can initiate network connections for legitimate purposes. However, adversaries exploit this by deploying malware in temporary directories to establish command and control (C2) channels. The detection rule identifies unusual executables making numerous outbound connections, excluding trusted IP ranges and known benign paths, to flag potential threats.
+
+### Possible investigation steps
+
+- Review the process.executable field to identify the specific executable making the connections and determine if it is known or expected in the environment.
+- Examine the destination.ip field to identify the external IP addresses the executable is attempting to connect to and check if they are known malicious or suspicious.
+- Check the host.os.type and agent.id fields to identify the specific host and agent involved, and gather additional context about the system's role and recent activity.
+- Analyze the @timestamp field to correlate the timing of the connections with other events or activities on the network or host.
+- Cross-reference the identified executable and IP addresses with threat intelligence sources to determine if they are associated with known threats or campaigns.
+- If the executable is determined to be malicious or suspicious, isolate the affected host and perform a deeper forensic analysis to identify any additional indicators of compromise or lateral movement.
+
+### False positive analysis
+
+- Executables in temporary directories used by legitimate applications or scripts can trigger alerts. Review the process name and executable path to determine if they are associated with known applications or scripts.
+- Automated scripts or cron jobs that perform network operations might be flagged. Identify these scripts and consider excluding their paths from the rule if they are verified as non-malicious.
+- Development or testing environments often use temporary directories for network operations. If these environments are known and trusted, add their specific paths to the exclusion list.
+- Backup or synchronization tools that use temporary directories for data transfer can generate numerous connections. Verify these tools and exclude their paths if they are confirmed to be safe.
+- Security tools or monitoring agents that operate in temporary directories might be mistakenly flagged. Confirm their legitimacy and exclude their paths to prevent false positives.
+
+### Response and remediation
+
+- Isolate the affected host immediately from the network to prevent further potential malicious communication and lateral movement.
+- Terminate the suspicious process identified by the alert to stop any ongoing malicious activity.
+- Conduct a forensic analysis of the affected system to identify any additional indicators of compromise (IOCs) and assess the extent of the infection.
+- Remove any malicious executables or files found in temporary directories such as /tmp, /var/tmp, or /dev/shm to eliminate the threat.
+- Patch and update the affected system to the latest security standards to close any vulnerabilities that may have been exploited.
+- Monitor network traffic for any unusual outbound connections from other systems to detect potential spread or similar threats.
+- Escalate the incident to the security operations center (SOC) or incident response team for further investigation and to ensure comprehensive remediation.
+"""
 risk_score = 47
 rule_id = "1fa350e0-0aa2-4055-bf8f-ab8b59233e59"
 setup = """## Setup
@@ -51,6 +87,7 @@ tags = [
     "Use Case: Threat Detection",
     "Tactic: Command and Control",
     "Data Source: Elastic Defend",
+    "Resources: Investigation Guide",
 ]
 timestamp_override = "event.ingested"
 type = "esql"