diff --git a/rules/integrations/azure_openai/azure_openai_denial_of_ml_service_detection.toml b/rules/integrations/azure_openai/azure_openai_denial_of_ml_service_detection.toml index 02094bccc60..e470b7e5e87 100644 --- a/rules/integrations/azure_openai/azure_openai_denial_of_ml_service_detection.toml +++ b/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" diff --git a/rules/integrations/azure_openai/azure_openai_insecure_output_handling_detection.toml b/rules/integrations/azure_openai/azure_openai_insecure_output_handling_detection.toml index 89bbc35bdd3..9a77b283ba6 100644 --- a/rules/integrations/azure_openai/azure_openai_insecure_output_handling_detection.toml +++ b/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" diff --git a/rules/integrations/azure_openai/azure_openai_model_theft_detection.toml b/rules/integrations/azure_openai/azure_openai_model_theft_detection.toml index 64877dfd53d..b1bb72f1ec6 100644 --- a/rules/integrations/azure_openai/azure_openai_model_theft_detection.toml +++ b/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" diff --git a/rules/linux/command_and_control_frequent_egress_netcon_from_sus_executable.toml b/rules/linux/command_and_control_frequent_egress_netcon_from_sus_executable.toml index 39523c012e0..31c51e7b607 100644 --- a/rules/linux/command_and_control_frequent_egress_netcon_from_sus_executable.toml +++ b/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" diff --git a/rules/linux/defense_evasion_authorized_keys_file_deletion.toml b/rules/linux/defense_evasion_authorized_keys_file_deletion.toml index e8d4b08fe06..0d34bf82dcd 100644 --- a/rules/linux/defense_evasion_authorized_keys_file_deletion.toml +++ b/rules/linux/defense_evasion_authorized_keys_file_deletion.toml @@ -2,7 +2,7 @@ creation_date = "2025/02/21" integration = ["endpoint"] maturity = "production" -updated_date = "2025/02/21" +updated_date = "2025/04/07" [rule] author = ["Elastic"] @@ -16,6 +16,42 @@ index = ["logs-endpoint.events.process*"] language = "eql" license = "Elastic License v2" name = "SSH Authorized Keys 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 SSH Authorized Keys File Deletion + +SSH authorized keys files are crucial for secure, password-less authentication on Linux systems, storing public keys that grant access. Adversaries may delete these files to disrupt legitimate access or cover their tracks. The detection rule identifies unauthorized deletions by monitoring file removal events, excluding benign processes, thus highlighting potential defense evasion tactics. + +### Possible investigation steps + +- Review the alert details to identify the specific file name (authorized_keys or authorized_keys2) and the host where the deletion occurred. +- Examine the process that triggered the deletion event, focusing on the process.executable field to determine if it is a known benign process or potentially malicious. +- Check the user account associated with the process that deleted the file to assess if it is a legitimate user or potentially compromised. +- Investigate recent login attempts and SSH access logs on the affected host to identify any unauthorized access or anomalies around the time of the file deletion. +- Look for any other suspicious activities or alerts on the same host that might indicate a broader attack or compromise, such as other file deletions or modifications. +- Assess the impact of the deletion by determining if legitimate access was disrupted and if any critical operations were affected. + +### False positive analysis + +- Routine system maintenance or updates may trigger deletions of authorized_keys files. To handle this, identify and exclude processes related to scheduled maintenance tasks from the detection rule. +- Automated configuration management tools like Ansible or Puppet might remove and recreate authorized_keys files as part of their operations. Consider excluding these tools' processes if they are verified as non-threatening. +- Cloud service agents, such as those from Google Cloud, may modify SSH keys as part of their operations. Ensure that processes like /usr/bin/google_guest_agent are excluded to prevent false positives. +- Container management services like Docker and containerd might interact with SSH keys during container lifecycle events. Exclude these processes if they are part of legitimate container operations. +- Custom scripts or applications that manage SSH keys for legitimate purposes should be reviewed and, if necessary, added to the exclusion list to prevent unnecessary alerts. + +### Response and remediation + +- Immediately isolate the affected system from the network to prevent further unauthorized access or potential lateral movement by the attacker. +- Verify the integrity of the SSH configuration and authorized keys files on the affected system. Restore the deleted authorized_keys or authorized_keys2 files from a secure backup if available. +- Conduct a thorough review of recent user and process activity on the affected system to identify any unauthorized access or suspicious behavior that may have led to the deletion. +- Change SSH keys and credentials for all users on the affected system to prevent unauthorized access using potentially compromised keys. +- Implement additional monitoring on the affected system to detect any further unauthorized file deletions or suspicious activities, ensuring that alerts are configured for immediate response. +- Escalate the incident to the security operations team for further investigation and to determine if the attack is part of a larger campaign targeting the organization. +- Review and update access controls and permissions on the affected system to ensure that only authorized users and processes can modify critical files like authorized_keys. +""" risk_score = 21 rule_id = "3c216ace-2633-4911-9aac-b61d4dc320e8" setup = """## Setup @@ -50,6 +86,7 @@ tags = [ "Use Case: Threat Detection", "Tactic: Defense Evasion", "Data Source: Elastic Defend", + "Resources: Investigation Guide", ] timestamp_override = "event.ingested" type = "eql" diff --git a/rules/linux/defense_evasion_base64_decoding_activity.toml b/rules/linux/defense_evasion_base64_decoding_activity.toml index 2697a85777a..291b5e6340c 100644 --- a/rules/linux/defense_evasion_base64_decoding_activity.toml +++ b/rules/linux/defense_evasion_base64_decoding_activity.toml @@ -2,7 +2,7 @@ creation_date = "2025/02/21" 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 = "Unusual Base64 Encoding/Decoding 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 Unusual Base64 Encoding/Decoding Activity +Base64 encoding is a method to convert binary data into ASCII text, often used for data transmission. Adversaries exploit this to obfuscate malicious payloads or commands, bypassing security controls. The detection rule identifies suspicious Base64 activity on Linux by monitoring specific processes and command patterns, flagging anomalies for further investigation. + +### Possible investigation steps + +- Review the process name and command line arguments to understand the context of the Base64 activity. Check if the process name matches known legitimate applications or scripts. +- Examine the timestamp of the event to determine if the activity occurred during normal operational hours or if it coincides with other suspicious activities. +- Investigate the host operating system type and agent ID to identify the specific Linux system involved and assess if it has a history of similar alerts or other security incidents. +- Analyze the process command line for any unusual patterns or parameters that might indicate obfuscation or malicious intent, such as the presence of decode flags or unexpected Base64 operations. +- Correlate the event with other logs or alerts from the same host or network to identify potential lateral movement or coordinated attacks. +- Check for any recent changes or deployments on the affected system that might explain the Base64 activity, such as new software installations or updates. +- Consult threat intelligence sources to determine if the observed Base64 patterns or command line arguments are associated with known malware or attack techniques. + +### False positive analysis + +- Routine administrative scripts may use base64 encoding for legitimate data processing tasks. Review the process.command_line and process.args fields to identify known scripts and consider excluding them from the rule. +- Backup or data transfer operations might employ base64 encoding to handle binary data. Verify the process.name and process.command_line to ensure these operations are recognized and add exceptions for these specific processes. +- Development environments often use base64 encoding for testing purposes. Identify development-related processes by examining the process.name and process.command_line and exclude them if they are part of regular development activities. +- Automated system monitoring tools might trigger this rule if they use base64 encoding for log or data analysis. Check the agent.id and process.command_line to confirm these tools and exclude them from the rule if they are verified as non-threatening. +- Security tools that perform data encoding for analysis or reporting could be flagged. Validate these tools by reviewing the process.name and process.command_line and create exceptions for them if they are part of the security infrastructure. + +### Response and remediation + +- Isolate the affected Linux system from the network to prevent further data exfiltration or lateral movement by the adversary. +- Terminate any suspicious processes identified by the alert, particularly those involving base64 encoding/decoding, to halt potential malicious activity. +- Conduct a thorough review of the process command lines and arguments flagged by the alert to identify any malicious scripts or payloads. Remove or quarantine these files as necessary. +- Check for any unauthorized user accounts or privilege escalations that may have been established during the attack and revoke access immediately. +- Restore any affected systems or files from a known good backup to ensure the integrity of the system and data. +- Implement additional monitoring on the affected system and similar environments to detect any recurrence of the suspicious base64 activity. +- Escalate the incident to the security operations center (SOC) or incident response team for further analysis and to determine if broader organizational impacts exist. +""" risk_score = 21 rule_id = "c5637438-e32d-4bb3-bc13-bd7932b3289f" setup = """## Setup @@ -52,6 +88,7 @@ tags = [ "Use Case: Threat Detection", "Tactic: Defense Evasion", "Data Source: Elastic Defend", + "Resources: Investigation Guide", ] timestamp_override = "event.ingested" type = "esql" diff --git a/rules/linux/defense_evasion_interpreter_launched_from_decoded_payload.toml b/rules/linux/defense_evasion_interpreter_launched_from_decoded_payload.toml index 8c03d97d941..1fefad94398 100644 --- a/rules/linux/defense_evasion_interpreter_launched_from_decoded_payload.toml +++ b/rules/linux/defense_evasion_interpreter_launched_from_decoded_payload.toml @@ -2,7 +2,7 @@ creation_date = "2025/02/21" integration = ["endpoint"] maturity = "production" -updated_date = "2025/02/21" +updated_date = "2025/04/07" [rule] author = ["Elastic"] @@ -16,6 +16,42 @@ index = ["logs-endpoint.events.process*"] language = "eql" license = "Elastic License v2" name = "Base64 Decoded Payload Piped to Interpreter" +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 Base64 Decoded Payload Piped to Interpreter + +Base64 encoding is a method to encode binary data into ASCII text, often used for data obfuscation. Adversaries exploit this by encoding malicious payloads and decoding them on a target system, piping the output to interpreters like bash or python for execution. The detection rule identifies such activities by monitoring for processes that decode Base64 and subsequently execute scripts, indicating potential malicious behavior. + +### Possible investigation steps + +- Review the process command line arguments to identify the specific Base64 decoding activity, focusing on the presence of flags like `-d` or `-a` in conjunction with tools such as `base64`, `openssl`, or scripting languages like `python`, `perl`, or `ruby`. +- Examine the parent process entity ID and command line to understand the context in which the Base64 decoding was initiated, identifying any potentially suspicious parent processes. +- Investigate the subsequent interpreter process that was executed, such as `bash`, `python`, or `ruby`, to determine the nature of the script or command being run, looking for any signs of malicious activity. +- Check the timing and sequence of the processes involved to confirm if the Base64 decoding and interpreter execution occurred within the specified maxspan of 3 seconds, indicating a likely automated or scripted action. +- Analyze the host ID and any associated user accounts to determine if the activity aligns with expected behavior for that system or user, or if it suggests unauthorized access or compromise. +- Correlate the alert with other security events or logs from the same host or user to identify any additional indicators of compromise or related suspicious activities. + +### False positive analysis + +- Legitimate administrative scripts may use Base64 encoding to handle data securely. Review the context of the script execution and consider excluding specific scripts or directories from monitoring if they are verified as safe. +- Automated backup or data transfer processes might use Base64 encoding for data integrity. Identify these processes and create exceptions for known, trusted applications or scripts. +- Development environments often use Base64 encoding for testing purposes. If a development tool or script is frequently triggering alerts, consider excluding the specific development environment or user accounts from this rule. +- Security tools or monitoring solutions may use Base64 encoding as part of their normal operations. Verify the source of the alert and exclude known security tools from triggering this rule. +- System updates or package installations might involve Base64 operations. Monitor the timing and context of these alerts and exclude specific update processes if they are consistently identified as false positives. + +### Response and remediation + +- Isolate the affected system from the network to prevent further execution of potentially malicious code and lateral movement. +- Terminate any suspicious processes identified by the detection rule, particularly those involving base64 decoding and piping to interpreters. +- Conduct a forensic analysis of the affected system to identify any additional indicators of compromise, such as unauthorized file modifications or network connections. +- Restore the system from a known good backup if malicious activity is confirmed and the integrity of the system is compromised. +- Update and patch all software and systems to mitigate vulnerabilities that could be exploited by similar techniques. +- Implement enhanced monitoring and logging for base64 decoding activities and interpreter executions to detect similar threats in the future. +- Escalate the incident to the security operations center (SOC) or incident response team for further investigation and to determine if broader organizational impacts exist. +""" risk_score = 47 rule_id = "5bdad1d5-5001-4a13-ae99-fa8619500f1a" setup = """## Setup @@ -51,6 +87,7 @@ tags = [ "Tactic: Defense Evasion", "Tactic: Execution", "Data Source: Elastic Defend", + "Resources: Investigation Guide", ] timestamp_override = "event.ingested" type = "eql" diff --git a/rules/linux/defense_evasion_kill_command_executed.toml b/rules/linux/defense_evasion_kill_command_executed.toml index b9af2419cac..ec54a5aa6be 100644 --- a/rules/linux/defense_evasion_kill_command_executed.toml +++ b/rules/linux/defense_evasion_kill_command_executed.toml @@ -2,7 +2,7 @@ creation_date = "2025/02/21" integration = ["endpoint"] maturity = "production" -updated_date = "2025/02/21" +updated_date = "2025/04/07" [rule] author = ["Elastic"] @@ -16,6 +16,40 @@ index = ["logs-endpoint.events.process*"] language = "kuery" license = "Elastic License v2" name = "Kill Command Execution" +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 Kill Command Execution +In Linux environments, commands like kill, pkill, and killall are essential for managing processes, allowing users to terminate them as needed. However, adversaries can exploit these commands to disable security tools or disrupt operations, aiding in evasion tactics. The detection rule identifies such misuse by monitoring process execution events, specifically targeting these commands to flag potential threats. + +### Possible investigation steps + +- Review the process execution event details to identify the user account associated with the kill, pkill, or killall command execution. This can help determine if the action was performed by a legitimate user or a potential adversary. +- Examine the parent process of the command execution to understand the context in which the kill command was initiated. This can provide insights into whether the command was part of a script or an interactive session. +- Check the target process IDs (PIDs) that were terminated by the kill command to assess if critical or security-related processes were affected, which might indicate malicious intent. +- Investigate the timing and frequency of the command execution to identify patterns or anomalies, such as repeated or scheduled executions, which could suggest automated or scripted activity. +- Correlate the event with other security alerts or logs from the same host around the same timeframe to identify any related suspicious activities or indicators of compromise. + +### False positive analysis + +- Routine system maintenance tasks may trigger the rule when administrators use kill commands to manage processes. To handle this, create exceptions for known maintenance scripts or processes by identifying their unique attributes, such as user or command line arguments. +- Automated scripts or monitoring tools that use kill commands for legitimate purposes, like restarting services, can cause false positives. Exclude these by specifying the script names or paths in the detection rule. +- Development environments where developers frequently use kill commands during testing can lead to alerts. Consider excluding processes executed by specific user accounts associated with development activities. +- System updates or package management tools might use kill commands as part of their operation. Identify these processes and exclude them based on their parent process or command line patterns. +- Backup or recovery operations that involve stopping services may trigger the rule. Exclude these by recognizing the specific backup software or service names involved. + +### Response and remediation + +- Immediately isolate the affected Linux system from the network to prevent further malicious activity or lateral movement by the attacker. +- Identify and terminate any unauthorized or suspicious processes that were started around the time of the alert, focusing on those that may have been targeted by the kill, pkill, or killall commands. +- Review system logs and process execution history to determine the origin of the kill command execution and assess whether it was initiated by a legitimate user or a compromised account. +- Restore any terminated security tools or critical processes to ensure the system's defenses are fully operational. +- Conduct a thorough scan of the affected system using updated antivirus or endpoint detection tools to identify and remove any additional malware or persistence mechanisms. +- Escalate the incident to the security operations center (SOC) or incident response team for further investigation and to determine if other systems may be affected. +- Implement additional monitoring and alerting for similar command executions across the network to enhance detection and response capabilities for future incidents. +""" risk_score = 21 rule_id = "f391d3fd-219b-42a3-9ba9-2f66eb0155aa" setup = """## Setup @@ -49,7 +83,8 @@ tags = [ "OS: Linux", "Use Case: Threat Detection", "Tactic: Defense Evasion", - "Data Source: Elastic Defend" + "Data Source: Elastic Defend", + "Resources: Investigation Guide", ] timestamp_override = "event.ingested" type = "new_terms" diff --git a/rules/linux/defense_evasion_var_log_file_creation_by_unsual_process.toml b/rules/linux/defense_evasion_var_log_file_creation_by_unsual_process.toml index 495f1231df6..062c9838029 100644 --- a/rules/linux/defense_evasion_var_log_file_creation_by_unsual_process.toml +++ b/rules/linux/defense_evasion_var_log_file_creation_by_unsual_process.toml @@ -4,7 +4,7 @@ integration = ["endpoint", "sentinel_one_cloud_funnel"] maturity = "production" min_stack_comments = "Breaking change at 8.13.0 for SentinelOne Integration." min_stack_version = "8.13.0" -updated_date = "2025/03/11" +updated_date = "2025/04/07" [rule] author = ["Elastic"] @@ -18,6 +18,41 @@ index = ["logs-endpoint.events.file*", "logs-sentinel_one_cloud_funnel.*", "endg language = "kuery" license = "Elastic License v2" name = "File Creation in /var/log via Suspicious Process" +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 File Creation in /var/log via Suspicious Process + +In Linux environments, the `/var/log` directory is crucial for storing system logs, which are essential for monitoring and troubleshooting. Adversaries may exploit this by creating files in this directory using executables from insecure locations, aiming to conceal their activities. The detection rule identifies such suspicious file creations by monitoring processes from world-writable or hidden paths, flagging potential evasion tactics. + +### Possible investigation steps + +- Review the process executable path to determine if it originates from a world-writable or hidden location such as /tmp, /var/tmp, /dev/shm, or similar directories. This can indicate potential malicious activity. +- Examine the process name and its parent process to understand the context of the file creation and identify if it is associated with known legitimate or suspicious activities. +- Check the file path in /var/log to see if the created file has any unusual naming conventions or lacks a file extension, which might suggest an attempt to hide or disguise the file. +- Investigate the user account under which the process was executed to determine if it has the necessary permissions and if the activity aligns with the user's typical behavior. +- Correlate the event with other logs or alerts from the same host to identify any related suspicious activities or patterns that could indicate a broader compromise. +- Assess the risk and impact of the file creation by considering the severity and risk score provided, and prioritize further actions based on this assessment. + +### False positive analysis + +- System maintenance scripts or legitimate applications may create temporary log files in /var/log using executables from directories like /tmp or /var/tmp. To handle this, identify and whitelist these known processes by their executable paths. +- Automated backup or monitoring tools might generate files in /var/log as part of their routine operations. Review these tools and exclude their processes from the rule to prevent unnecessary alerts. +- Development or testing environments often involve scripts that create log files in /var/log for debugging purposes. Consider excluding these environments from the rule or creating specific exceptions for known development processes. +- Some system updates or package installations might temporarily use world-writable directories for executable scripts that interact with /var/log. Monitor these activities and create exceptions for trusted update processes to reduce false positives. + +### Response and remediation + +- Isolate the affected system from the network to prevent further malicious activity and lateral movement. +- Terminate any suspicious processes identified as originating from world-writable or hidden paths, especially those involved in file creation within /var/log. +- Conduct a thorough review of the files created in /var/log to determine if they contain malicious content or scripts, and remove any unauthorized files. +- Restore any affected system files or logs from a known good backup to ensure system integrity and continuity of logging. +- Implement stricter permissions on directories like /tmp, /var/tmp, and /dev/shm to prevent unauthorized execution of processes from these locations. +- Escalate the incident to the security operations team for further analysis and to determine if additional systems are compromised. +- Update and enhance monitoring rules to detect similar suspicious activities in the future, focusing on process execution from insecure locations and unauthorized file creation in critical directories. +""" risk_score = 21 rule_id = "ddf26e25-3e30-42b2-92db-bde8eb82ad67" setup = """## Setup @@ -56,6 +91,7 @@ tags = [ "Data Source: Elastic Defend", "Data Source: SentinelOne", "Data Source: Elastic Endgame", + "Resources: Investigation Guide", ] timestamp_override = "event.ingested" type = "new_terms" diff --git a/rules/linux/discovery_docker_socket_discovery.toml b/rules/linux/discovery_docker_socket_discovery.toml index bf00ef7c0d9..1cd511a6daf 100644 --- a/rules/linux/discovery_docker_socket_discovery.toml +++ b/rules/linux/discovery_docker_socket_discovery.toml @@ -2,7 +2,7 @@ creation_date = "2025/03/04" integration = ["endpoint", "auditd_manager", "crowdstrike", "sentinel_one_cloud_funnel"] maturity = "production" -updated_date = "2025/03/20" +updated_date = "2025/04/07" [rule] author = ["Elastic"] @@ -25,6 +25,42 @@ index = [ language = "eql" license = "Elastic License v2" name = "Docker Socket Enumeration" +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 Docker Socket Enumeration + +Docker sockets facilitate communication between the Docker client and daemon, enabling container management. Adversaries exploit this by accessing the socket to control containers, potentially escalating privileges or moving laterally. The detection rule identifies suspicious processes interacting with the Docker socket, using specific commands, to flag unauthorized enumeration attempts. + +### Possible investigation steps + +- Review the process details to confirm the presence of suspicious commands interacting with the Docker socket, specifically looking for the use of tools like curl, socat, nc, netcat, ncat, or nc.traditional. +- Examine the command line arguments of the flagged process to understand the intent and scope of the interaction with the Docker socket, focusing on paths like /var/run/docker.sock or /run/docker.sock. +- Identify the user account under which the suspicious process was executed to assess if it has legitimate access to Docker resources or if it might be compromised. +- Check the historical activity of the involved user and process to determine if this behavior is anomalous or part of a known pattern. +- Investigate any recent changes or deployments in the Docker environment that might explain the interaction with the Docker socket, such as new container setups or updates. +- Correlate the alert with other security events or logs from the same host or network segment to identify potential lateral movement or privilege escalation attempts. + +### False positive analysis + +- Legitimate administrative tasks using tools like curl or socat to interact with Docker for monitoring or management purposes can trigger alerts. To handle this, create exceptions for specific user accounts or scripts that are known to perform these tasks regularly. +- Automated scripts or services that check the status of Docker containers might be flagged. Identify these scripts and whitelist their process names or command lines to prevent unnecessary alerts. +- Development environments where developers frequently use command-line tools to interact with Docker may cause false positives. Consider excluding specific development machines or user groups from the rule to reduce noise. +- Continuous integration or deployment pipelines that use Docker commands as part of their workflow can be mistaken for enumeration attempts. Exclude these processes by identifying their unique command patterns or execution contexts. +- Security tools that perform regular audits or checks on Docker environments might trigger the rule. Verify these tools and add them to an exception list to avoid false alerts. + +### Response and remediation + +- Immediately isolate the affected host from the network to prevent further unauthorized access or lateral movement. +- Terminate any suspicious processes identified in the alert that are interacting with the Docker socket, such as those using curl, socat, or netcat. +- Conduct a thorough review of Docker containers on the affected host to identify any unauthorized or malicious containers. Stop and remove any that are not recognized or are deemed suspicious. +- Check for any unauthorized changes to Docker configurations or images and revert them to a known good state. +- Review and restrict permissions on the Docker socket file (/var/run/docker.sock) to limit access to only trusted users and processes. +- Escalate the incident to the security operations team for further investigation and to determine if additional hosts or systems are affected. +- Implement enhanced monitoring and logging for Docker socket interactions to detect and respond to similar threats more quickly in the future. +""" risk_score = 21 rule_id = "dd983e79-22e8-44d1-9173-d57dba514cac" setup = """## Setup @@ -64,6 +100,7 @@ tags = [ "Data Source: Auditd Manager", "Data Source: Crowdstrike", "Data Source: SentinelOne", + "Resources: Investigation Guide", ] timestamp_override = "event.ingested" type = "eql" diff --git a/rules/linux/discovery_port_scanning_activity_from_compromised_host.toml b/rules/linux/discovery_port_scanning_activity_from_compromised_host.toml index fe826311bea..5b0e0cc6d7b 100644 --- a/rules/linux/discovery_port_scanning_activity_from_compromised_host.toml +++ b/rules/linux/discovery_port_scanning_activity_from_compromised_host.toml @@ -2,7 +2,7 @@ creation_date = "2025/03/04" integration = ["endpoint"] maturity = "production" -updated_date = "2025/04/03" +updated_date = "2025/04/07" [rule] author = ["Elastic"] @@ -19,6 +19,42 @@ interval = "1h" language = "esql" license = "Elastic License v2" name = "Potential Port Scanning Activity from Compromised Host" +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 Port Scanning Activity from Compromised Host + +Port scanning is a reconnaissance method used by attackers to identify open ports and services on a network, often as a precursor to exploitation. In Linux environments, compromised hosts may perform rapid connection attempts to numerous ports, signaling potential scanning activity. The detection rule identifies such behavior by analyzing network logs for a high number of distinct port connections from a single host within a short timeframe, indicating possible malicious intent. + +### Possible investigation steps + +- Review the network logs to identify the specific host exhibiting the port scanning behavior by examining the destination.ip and process.executable fields. +- Analyze the @timestamp field to determine the exact time frame of the scanning activity and correlate it with any other suspicious activities or alerts from the same host. +- Investigate the process.executable field to understand which application or service initiated the connection attempts, and verify if it is a legitimate process or potentially malicious. +- Check the destination.port field to identify the range and types of ports targeted by the scanning activity, which may provide insights into the attacker's objectives or the services they are interested in. +- Assess the host's security posture by reviewing recent changes, installed software, and user activity to determine if the host has been compromised or if the scanning is part of legitimate network operations. +- Consult the original documents and logs for additional context and details that may not be captured in the alert to aid in a comprehensive investigation. + +### False positive analysis + +- Legitimate network scanning tools used by system administrators for network maintenance or security assessments can trigger this rule. To handle this, identify and whitelist the IP addresses or processes associated with these tools. +- Automated vulnerability scanners or monitoring systems that perform regular checks on network services may cause false positives. Exclude these systems by creating exceptions for their known IP addresses or process names. +- High-volume legitimate services that open multiple connections to different ports, such as load balancers or proxy servers, might be flagged. Review and exclude these services by specifying their IP addresses or process executables. +- Development or testing environments where frequent port scanning is part of routine operations can be mistakenly identified. Implement exceptions for these environments by excluding their specific network segments or host identifiers. +- Scheduled network discovery tasks that are part of IT operations can mimic port scanning behavior. Document and exclude these tasks by setting up time-based exceptions or identifying their unique process signatures. + +### Response and remediation + +- Isolate the compromised host from the network immediately to prevent further scanning and potential lateral movement. +- Terminate any suspicious processes identified by the process.executable field to halt ongoing malicious activities. +- Conduct a thorough review of the compromised host's system logs and network traffic to identify any unauthorized access or data exfiltration attempts. +- Patch and update all software and services on the compromised host to close any vulnerabilities that may have been exploited. +- Change all credentials associated with the compromised host and any potentially affected systems to prevent unauthorized access. +- Monitor the network for any further signs of scanning activity or other suspicious behavior from other hosts, indicating potential additional compromises. +- Escalate the incident to the security operations team for further investigation and to determine if additional systems are affected. +""" risk_score = 21 rule_id = "6b341d03-1d63-41ac-841a-2009c86959ca" setup = """## Setup @@ -53,6 +89,7 @@ tags = [ "Use Case: Threat Detection", "Tactic: Discovery", "Data Source: Elastic Defend", + "Resources: Investigation Guide", ] timestamp_override = "event.ingested" type = "esql" diff --git a/rules/linux/discovery_subnet_scanning_activity_from_compromised_host.toml b/rules/linux/discovery_subnet_scanning_activity_from_compromised_host.toml index b09c57897a5..1e13ae504e3 100644 --- a/rules/linux/discovery_subnet_scanning_activity_from_compromised_host.toml +++ b/rules/linux/discovery_subnet_scanning_activity_from_compromised_host.toml @@ -2,7 +2,7 @@ creation_date = "2025/03/04" integration = ["endpoint"] maturity = "production" -updated_date = "2025/04/03" +updated_date = "2025/04/07" [rule] author = ["Elastic"] @@ -19,6 +19,41 @@ interval = "1h" language = "esql" license = "Elastic License v2" name = "Potential Subnet Scanning Activity from Compromised Host" +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 Subnet Scanning Activity from Compromised Host + +Subnet scanning is a reconnaissance method used by attackers to map network topology and identify active hosts. Adversaries exploit compromised hosts to perform these scans, seeking vulnerabilities for further attacks. The detection rule identifies such activity by monitoring Linux hosts for numerous connection attempts to different IPs within a short period, indicating potential scanning behavior. This helps in early detection and mitigation of network threats. + +### Possible investigation steps + +- Review the process executable identified in the alert to determine if it is a known or legitimate application that should be making network connections. +- Examine the destination IP addresses to identify any patterns or known malicious IPs, and check if these IPs are part of the organization's network or external. +- Investigate the specific host (using the agent.id) to assess if there are any signs of compromise, such as unusual processes or unauthorized access. +- Correlate the event timestamp with other logs or alerts to identify any concurrent suspicious activities or anomalies on the host. +- Check for any recent changes or updates on the host that might explain the scanning behavior, such as new software installations or configuration changes. + +### False positive analysis + +- High-volume legitimate network monitoring tools may trigger the rule. Identify and exclude these tools by adding their process executables to an exception list. +- Automated backup systems that connect to multiple hosts within a short timeframe can be mistaken for scanning activity. Review and exclude these systems by their process executable or agent ID. +- Security software performing routine network health checks might generate false positives. Verify these activities and create exceptions based on the specific process executable involved. +- Internal IT scripts or administrative tasks that involve connecting to numerous hosts for maintenance purposes can trigger alerts. Document these tasks and exclude them by process executable or agent ID. +- Cloud-based services or applications that require frequent connections to various hosts for functionality may appear as scanning. Identify these services and exclude them by their process executable or agent ID. + +### Response and remediation + +- Isolate the compromised host immediately from the network to prevent further scanning and potential lateral movement by the attacker. +- Terminate any suspicious processes identified by the executable name in the alert to stop ongoing scanning activities. +- Conduct a thorough examination of the compromised host to identify and remove any malware or unauthorized access tools that may have been installed. +- Reset credentials and review access permissions for the compromised host to ensure no unauthorized access persists. +- Update and patch the compromised host and any other vulnerable systems identified during the investigation to close security gaps. +- Monitor network traffic closely for any signs of continued scanning or other suspicious activities from other hosts, indicating potential further compromise. +- Escalate the incident to the security operations center (SOC) or incident response team for a comprehensive investigation and to determine if additional hosts are affected. +""" risk_score = 21 rule_id = "860f2a03-a1cf-48d6-a674-c6d62ae608a1" setup = """## Setup @@ -53,6 +88,7 @@ tags = [ "Use Case: Threat Detection", "Tactic: Discovery", "Data Source: Elastic Defend", + "Resources: Investigation Guide", ] timestamp_override = "event.ingested" type = "esql" diff --git a/rules/linux/exfiltration_unusual_file_transfer_utility_launched.toml b/rules/linux/exfiltration_unusual_file_transfer_utility_launched.toml index fdc095ff85e..f3520928930 100644 --- a/rules/linux/exfiltration_unusual_file_transfer_utility_launched.toml +++ b/rules/linux/exfiltration_unusual_file_transfer_utility_launched.toml @@ -2,7 +2,7 @@ creation_date = "2025/02/21" integration = ["endpoint"] maturity = "production" -updated_date = "2025/04/03" +updated_date = "2025/04/07" [rule] author = ["Elastic"] @@ -16,6 +16,41 @@ interval = "1h" language = "esql" license = "Elastic License v2" name = "Unusual File Transfer Utility Launched" +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 Unusual File Transfer Utility Launched + +File transfer utilities like scp, ftp, and rsync are essential for data movement in Linux environments. However, adversaries can exploit these tools to exfiltrate sensitive data. The detection rule identifies suspicious executions of these utilities by monitoring process activities, focusing on rare occurrences and unique agent IDs, which may indicate unauthorized data transfers. This helps in early detection of potential data breaches. + +### Possible investigation steps + +- Review the process.command_line field to understand the exact command executed and assess if it aligns with typical usage patterns or if it appears suspicious. +- Examine the process.parent.executable field to determine the parent process that initiated the file transfer utility, which may provide insights into whether the execution was part of a legitimate workflow or potentially malicious activity. +- Check the agent.id field to identify the specific host involved in the alert and correlate it with other security events or logs from the same host to gather additional context. +- Investigate the @timestamp field to verify the timing of the event and cross-reference with any known scheduled tasks or user activities that could explain the execution. +- Analyze the host.os.type field to confirm the operating system and ensure that the alert pertains to a Linux environment, as expected by the rule. + +### False positive analysis + +- Routine administrative tasks using file transfer utilities may trigger alerts. Regularly scheduled backups or updates using scp, rsync, or ftp should be documented and excluded from alerts by creating exceptions for known scripts or cron jobs. +- Automated system updates or patches that utilize these utilities can be mistaken for suspicious activity. Identify and whitelist the processes and command lines associated with these updates to prevent false positives. +- Internal data transfers between trusted servers for legitimate business purposes might be flagged. Establish a list of trusted agent IDs and exclude them from the rule to avoid unnecessary alerts. +- Development and testing environments often use these utilities for transferring test data. Ensure that these environments are recognized and excluded by specifying their hostnames or IP addresses in the rule configuration. +- User-initiated file transfers for legitimate reasons, such as data analysis or reporting, can be misinterpreted. Educate users to notify the security team of such activities in advance, allowing for temporary exceptions to be made. + +### Response and remediation + +- Immediately isolate the affected Linux system from the network to prevent further data exfiltration and unauthorized access. +- Terminate any suspicious file transfer processes identified by the alert, such as scp, ftp, or rsync, to halt ongoing data transfers. +- Conduct a thorough review of the process command lines and parent executables to identify any malicious scripts or unauthorized software that initiated the file transfer. +- Change credentials and access keys associated with the compromised system to prevent further unauthorized access. +- Escalate the incident to the security operations team for a deeper forensic analysis to determine the extent of the breach and identify any additional compromised systems. +- Implement network monitoring to detect any further attempts of unauthorized file transfers or suspicious activities from the affected system. +- Update and enhance endpoint detection and response (EDR) solutions to improve detection capabilities for similar threats in the future. +""" risk_score = 21 rule_id = "8eeeda11-dca6-4c3e-910f-7089db412d1c" setup = """## Setup @@ -52,6 +87,7 @@ tags = [ "Tactic: Exfiltration", "Tactic: Execution", "Data Source: Elastic Defend", + "Resources: Investigation Guide", ] timestamp_override = "event.ingested" type = "esql" diff --git a/rules/linux/impact_potential_bruteforce_malware_infection.toml b/rules/linux/impact_potential_bruteforce_malware_infection.toml index 2453ee5c600..ff69827b669 100644 --- a/rules/linux/impact_potential_bruteforce_malware_infection.toml +++ b/rules/linux/impact_potential_bruteforce_malware_infection.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"] @@ -20,6 +20,41 @@ interval = "1h" language = "esql" license = "Elastic License v2" name = "Potential Malware-Driven SSH Brute Force Attempt" +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 Malware-Driven SSH Brute Force Attempt + +SSH is a protocol used to securely access remote systems. Adversaries exploit it by deploying malware on compromised Linux hosts to perform brute-force attacks, attempting unauthorized access to other systems. The detection rule identifies such abuse by monitoring high volumes of outbound SSH connection attempts from a single process to external IPs, indicating potential malware activity. + +### Possible investigation steps + +- Review the process executable identified in the alert to determine if it is a legitimate application or potentially malicious. Check for known malware signatures or unusual file paths. +- Analyze the destination IP addresses involved in the connection attempts to identify if they are known malicious hosts or part of a larger attack infrastructure. Use threat intelligence sources to gather more information. +- Examine the host's recent activity logs to identify any unusual behavior or signs of compromise, such as unexpected process executions or changes in system configurations. +- Investigate the specific agent.id associated with the alert to determine if other alerts or suspicious activities have been reported from the same host, indicating a broader compromise. +- Check for any recent changes or updates to the host's software or configurations that could have introduced vulnerabilities exploited by the malware. +- Assess the network traffic patterns from the host to identify any other unusual outbound connections that may indicate additional malicious activity or data exfiltration attempts. + +### False positive analysis + +- High-volume legitimate SSH operations from a single process can trigger alerts. Exclude known safe processes or scripts that perform frequent SSH operations by adding them to an exception list. +- Automated backup or synchronization tools using SSH to connect to external servers may be misidentified. Identify these tools and exclude their process names or IP addresses from the detection rule. +- Development or testing environments where SSH connections are frequently initiated to external systems for legitimate purposes can cause false positives. Document these environments and adjust the rule to exclude their specific IP ranges or process identifiers. +- Security scanning tools that perform SSH checks on external systems might be flagged. Ensure these tools are recognized and their activities are excluded by specifying their process names or IP addresses in the rule exceptions. + +### Response and remediation + +- Isolate the affected Linux host from the network immediately to prevent further unauthorized access attempts and potential spread of malware to other systems. +- Terminate the suspicious process identified by the detection rule to stop ongoing brute-force attempts and reduce the risk of further compromise. +- Conduct a thorough malware scan on the isolated host using updated antivirus or endpoint detection and response (EDR) tools to identify and remove any malicious software. +- Review and reset credentials for any accounts that may have been targeted or compromised during the brute-force attempts to ensure account security. +- Apply security patches and updates to the affected host and any other vulnerable systems to mitigate known vulnerabilities that could be exploited by similar threats. +- Monitor network traffic for any signs of continued or new suspicious activity, particularly focusing on outbound SSH connections, to detect and respond to any further attempts promptly. +- Escalate the incident to the security operations center (SOC) or relevant security team for further investigation and to assess the potential impact on the broader network infrastructure. +""" risk_score = 47 rule_id = "77122db4-5876-4127-b91b-6c179eb21f88" setup = """## Setup @@ -56,6 +91,7 @@ tags = [ "Tactic: Execution", "Tactic: Command and Control", "Data Source: Elastic Defend", + "Resources: Investigation Guide", ] timestamp_override = "event.ingested" type = "esql" diff --git a/rules/linux/initial_access_first_time_public_key_authentication.toml b/rules/linux/initial_access_first_time_public_key_authentication.toml index 79f2452eeb7..d4291121e79 100644 --- a/rules/linux/initial_access_first_time_public_key_authentication.toml +++ b/rules/linux/initial_access_first_time_public_key_authentication.toml @@ -2,7 +2,7 @@ creation_date = "2025/02/21" integration = ["system"] maturity = "production" -updated_date = "2025/02/21" +updated_date = "2025/04/07" [rule] author = ["Elastic"] @@ -22,6 +22,42 @@ index = ["logs-system.auth-*", "filebeat-*"] language = "kuery" license = "Elastic License v2" name = "Successful SSH Authentication from Unusual SSH Public Key" +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 Successful SSH Authentication from Unusual SSH Public Key + +SSH public key authentication is a secure method for accessing Linux systems, relying on cryptographic keys rather than passwords. Adversaries may exploit this by using stolen or unauthorized keys to gain access. The detection rule identifies successful logins using new public keys, unseen in the past 10 days, signaling potential unauthorized access attempts. This helps in early detection of suspicious activities, aligning with threat tactics like Initial Access. + +### Possible investigation steps + +- Review the specific SSH login event details, focusing on the event.category, event.action, and event.outcome fields to confirm the successful authentication via public key. +- Identify the source IP address and user account associated with the login event to determine if they are known or expected. +- Check the system.auth.ssh.method field to ensure the authentication method was indeed public key and not another method. +- Investigate the history of the public key used for authentication by searching logs for any previous occurrences or related activities within the last 10 days. +- Correlate the event with other security logs or alerts from the same host or user to identify any patterns or additional suspicious activities. +- Assess the risk by considering the context of the login, such as the time of access, the location of the source IP, and any recent changes in user behavior or system configurations. +- If unauthorized access is suspected, initiate incident response procedures, including revoking the public key, notifying affected parties, and conducting a thorough security review of the system. + +### False positive analysis + +- Frequent logins from known automation scripts or services using rotating SSH keys can trigger false positives. To manage this, identify these services and add their public keys to an exception list. +- Developers or system administrators who regularly update their SSH keys for security reasons may cause alerts. Maintain a record of authorized personnel and their key update schedules to exclude these events. +- Temporary access granted to third-party vendors or contractors might appear as unusual activity. Ensure that any temporary access is documented and keys are added to an exception list during the access period. +- Test environments where SSH keys are frequently generated and used for various testing purposes can lead to false positives. Implement a separate monitoring policy for test environments to reduce noise in production alerts. + +### Response and remediation + +- Immediately isolate the affected system from the network to prevent further unauthorized access or lateral movement by the adversary. +- Revoke the unauthorized SSH public key from the system's authorized_keys file to block further access using that key. +- Conduct a thorough review of recent login activities and system logs to identify any additional unauthorized access or suspicious activities that may have occurred. +- Change passwords and regenerate SSH keys for all legitimate users on the affected system to ensure no compromised credentials remain in use. +- Notify the security team and relevant stakeholders about the incident for awareness and further investigation. +- Implement additional monitoring on the affected system and related network segments to detect any further suspicious activities or attempts to regain access. +- Review and update access control policies and SSH key management practices to prevent similar incidents in the future, ensuring that only authorized keys are allowed and regularly audited. +""" risk_score = 21 rule_id = "267dace3-a4de-4c94-a7b5-dd6c0f5482e5" setup = """## Setup @@ -51,7 +87,8 @@ tags = [ "OS: Linux", "Use Case: Threat Detection", "Tactic: Initial Access", - "Data Source: Elastic Defend" + "Data Source: Elastic Defend", + "Resources: Investigation Guide", ] timestamp_override = "event.ingested" type = "new_terms" diff --git a/rules/linux/initial_access_successful_ssh_authentication_by_unusual_ip.toml b/rules/linux/initial_access_successful_ssh_authentication_by_unusual_ip.toml index dc8425e0e83..ba1728e7df7 100644 --- a/rules/linux/initial_access_successful_ssh_authentication_by_unusual_ip.toml +++ b/rules/linux/initial_access_successful_ssh_authentication_by_unusual_ip.toml @@ -2,7 +2,7 @@ creation_date = "2025/02/21" integration = ["system"] maturity = "production" -updated_date = "2025/02/21" +updated_date = "2025/04/07" [rule] author = ["Elastic"] @@ -16,6 +16,41 @@ index = ["logs-system.auth-*", "filebeat-*"] language = "kuery" license = "Elastic License v2" name = "Successful SSH Authentication from Unusual IP Address" +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 Successful SSH Authentication from Unusual IP Address + +Secure Shell (SSH) is a protocol used to securely access and manage Linux systems. Adversaries may exploit SSH by using stolen credentials to gain unauthorized access. The detection rule identifies successful logins from IPs not seen in the past 10 days, flagging potential intrusions. This approach helps in spotting unusual access patterns that could indicate compromised accounts. + +### Possible investigation steps + +- Review the IP address flagged in the alert to determine its geolocation and assess if it aligns with expected access patterns for the user account involved. +- Check historical authentication logs for the user account to identify any other unusual or unauthorized access attempts, focusing on the event.category:authentication and event.action:ssh_login fields. +- Investigate the user account's recent activity on the system to identify any suspicious commands or actions executed post-authentication. +- Correlate the flagged IP address with known threat intelligence sources to determine if it is associated with any malicious activity or previously reported incidents. +- Contact the user associated with the account to verify if they recognize the login attempt and if they have recently accessed the system from a new location or device. + +### False positive analysis + +- New employee or contractor access from a previously unseen IP address may trigger the rule. Regularly update the list of known IP addresses for new users to prevent unnecessary alerts. +- Remote workers or employees traveling may log in from different IP addresses. Implement a process to whitelist IP ranges associated with common travel destinations or VPNs used by the organization. +- Automated scripts or services that occasionally run from different IPs can cause false positives. Identify and document these services, then create exceptions for their known IP addresses. +- Cloud-based infrastructure changes, such as new instances or containers, might authenticate from new IPs. Maintain an updated inventory of cloud resources and their expected IP ranges to adjust the rule accordingly. +- Third-party vendors accessing systems for maintenance or support might use different IPs. Establish a protocol for temporary exceptions for vendor IPs during their access periods. + +### Response and remediation + +- Immediately isolate the affected system from the network to prevent further unauthorized access or lateral movement by the attacker. +- Verify the legitimacy of the login by contacting the account owner to confirm whether the access was authorized. If unauthorized, proceed with further steps. +- Change the password of the compromised account and any other accounts that may have been accessed using the same credentials. +- Review and analyze the system logs for any additional suspicious activity or changes made during the unauthorized access period. +- Escalate the incident to the security operations team for a thorough investigation and to determine if further systems are affected. +- Implement IP whitelisting or geofencing to restrict SSH access to known and trusted IP addresses only. +- Update and enhance monitoring rules to detect similar unauthorized access attempts in the future, ensuring that alerts are promptly reviewed and acted upon. +""" risk_score = 21 rule_id = "5c495612-9992-49a7-afe3-0f647671fb60" setup = """## Setup @@ -45,7 +80,8 @@ tags = [ "OS: Linux", "Use Case: Threat Detection", "Tactic: Initial Access", - "Data Source: Elastic Defend" + "Data Source: Elastic Defend", + "Resources: Investigation Guide", ] timestamp_override = "event.ingested" type = "new_terms" diff --git a/rules/linux/initial_access_successful_ssh_authentication_by_unusual_user.toml b/rules/linux/initial_access_successful_ssh_authentication_by_unusual_user.toml index b1ca9ab719d..02da411c3c8 100644 --- a/rules/linux/initial_access_successful_ssh_authentication_by_unusual_user.toml +++ b/rules/linux/initial_access_successful_ssh_authentication_by_unusual_user.toml @@ -2,7 +2,7 @@ creation_date = "2025/02/21" integration = ["system"] maturity = "production" -updated_date = "2025/02/21" +updated_date = "2025/04/07" [rule] author = ["Elastic"] @@ -21,6 +21,41 @@ index = ["logs-system.auth-*", "filebeat-*"] language = "kuery" license = "Elastic License v2" name = "Successful SSH Authentication from Unusual 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 Successful SSH Authentication from Unusual User + +SSH (Secure Shell) is a protocol used to securely access and manage Linux systems. Adversaries may exploit valid user accounts to gain unauthorized access, bypassing traditional security measures. The detection rule identifies unusual SSH logins by flagging users who haven't logged in for over 10 days, indicating potential misuse of credentials. This proactive approach helps in early detection of unauthorized access attempts. + +### Possible investigation steps + +- Review the specific user account involved in the alert to determine if the login is expected or authorized, considering the user's typical login patterns and responsibilities. +- Check the source IP address of the SSH login to see if it is recognized or associated with previous legitimate access, or if it appears unusual or suspicious. +- Analyze the timing of the login event to see if it coincides with any known maintenance windows or scheduled activities that could explain the access. +- Investigate any recent changes to the user's account, such as password resets or modifications to permissions, that could indicate potential compromise. +- Correlate the SSH login event with other logs or alerts from the same timeframe to identify any additional suspicious activities or patterns that could suggest a broader security incident. + +### False positive analysis + +- Users returning from extended leave or vacation may trigger the rule. To manage this, create exceptions for users with known absence periods. +- System administrators or service accounts that log in infrequently for maintenance tasks can be excluded by identifying and documenting these accounts. +- Automated scripts or processes that authenticate sporadically might be flagged. Review and whitelist these processes if they are legitimate and necessary for operations. +- Temporary contractors or consultants with limited access periods may cause alerts. Ensure their access is documented and create exceptions for their accounts during their engagement period. +- Accounts used for testing or development purposes that are not regularly active can be excluded by maintaining a list of such accounts and updating it as needed. + +### Response and remediation + +- Immediately isolate the affected system from the network to prevent further unauthorized access or lateral movement by the attacker. +- Terminate the active SSH session associated with the unusual login to cut off the attacker's access. +- Reset the password for the compromised user account and any other accounts that may have been accessed using the same credentials. +- Conduct a thorough review of the affected system's logs and configurations to identify any unauthorized changes or additional compromised accounts. +- Escalate the incident to the security operations team for further investigation and to determine if additional systems or accounts have been affected. +- Implement multi-factor authentication (MFA) for SSH access to enhance security and prevent similar unauthorized access attempts in the future. +- Update and enhance monitoring rules to detect similar unusual login patterns, ensuring early detection of potential threats. +""" risk_score = 21 rule_id = "5b8d7b94-23c6-4e3f-baed-3a4d0da4f19d" severity = "low" @@ -29,7 +64,8 @@ tags = [ "OS: Linux", "Use Case: Threat Detection", "Tactic: Initial Access", - "Data Source: Elastic Defend" + "Data Source: Elastic Defend", + "Resources: Investigation Guide", ] timestamp_override = "event.ingested" type = "new_terms" diff --git a/rules/linux/lateral_movement_remote_file_creation_world_writeable_dir.toml b/rules/linux/lateral_movement_remote_file_creation_world_writeable_dir.toml index c6bed10609b..758bad70443 100644 --- a/rules/linux/lateral_movement_remote_file_creation_world_writeable_dir.toml +++ b/rules/linux/lateral_movement_remote_file_creation_world_writeable_dir.toml @@ -2,7 +2,7 @@ creation_date = "2025/02/20" integration = ["endpoint"] maturity = "production" -updated_date = "2025/02/20" +updated_date = "2025/04/07" [rule] author = ["Elastic"] @@ -16,6 +16,42 @@ index = ["logs-endpoint.events.file*", "auditbeat-*"] language = "eql" license = "Elastic License v2" name = "Remote File Creation in World Writeable Directory" +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 Remote File Creation in World Writeable Directory + +In Linux environments, world-writeable directories like `/tmp` and `/var/tmp` are used for temporary file storage, accessible by all users. Adversaries exploit these directories to deposit malicious files via remote services such as SSH or FTP, facilitating lateral movement. The detection rule identifies file creation events in these directories by non-root users using common file transfer services, signaling potential unauthorized activity. + +### Possible investigation steps + +- Review the file creation event details, focusing on the file path to determine if it matches any known malicious patterns or if it is unusual for the environment. +- Identify the user associated with the file creation event by examining the user.id field, and verify if this user should have access to the affected directory. +- Investigate the process responsible for the file creation by analyzing the process.name field to determine if it aligns with expected usage patterns for the user and system. +- Check the source IP address and connection details related to the file transfer service used (e.g., SSH, FTP) to identify any suspicious or unauthorized access attempts. +- Correlate the event with other recent activities on the host to identify any patterns of lateral movement or other suspicious behavior. +- Review historical data for similar file creation events by the same user or process to assess if this is part of a recurring pattern or an isolated incident. + +### False positive analysis + +- Routine administrative tasks: System administrators often use file transfer services like scp or rsync to move files for legitimate purposes. To reduce false positives, create exceptions for known administrative accounts or specific file paths that are regularly used for maintenance. +- Automated scripts and cron jobs: Automated processes may create temporary files in world-writeable directories. Identify and whitelist these scripts or jobs by their process names or user accounts to prevent unnecessary alerts. +- Software updates and installations: Some software updates or installations may temporarily use world-writeable directories. Monitor and document these activities, and consider excluding specific update processes or package managers from the rule. +- Development and testing environments: Developers may use these directories for testing purposes. Establish a separate monitoring policy for development environments or exclude known developer accounts to minimize false positives. +- Backup operations: Backup tools might use temporary directories for staging files. Identify these tools and their typical behavior, and create exceptions based on their process names or user IDs. + +### Response and remediation + +- Immediately isolate the affected system from the network to prevent further lateral movement by the adversary. +- Terminate any suspicious processes associated with file transfer services (e.g., scp, ssh, ftp) that are not part of legitimate user activity. +- Remove any unauthorized files created in world-writeable directories such as /tmp, /var/tmp, or /dev/shm to eliminate potential threats. +- Conduct a thorough review of user accounts and permissions, focusing on non-root users who have recently accessed the system, to identify any unauthorized access. +- Reset credentials for compromised or potentially compromised accounts to prevent further unauthorized access. +- Monitor network traffic for unusual patterns or connections to external IP addresses that may indicate ongoing or additional compromise attempts. +- Escalate the incident to the security operations team for further investigation and to determine if additional systems have been affected, ensuring a coordinated response. +""" risk_score = 47 rule_id = "3e528511-7316-4a6e-83da-61b5f1c07fd4" setup = """## Setup @@ -62,6 +98,7 @@ tags = [ "Use Case: Threat Detection", "Tactic: Lateral Movement", "Data Source: Elastic Defend", + "Resources: Investigation Guide", ] timestamp_override = "event.ingested" type = "eql" diff --git a/rules/linux/lateral_movement_unusual_remote_file_creation.toml b/rules/linux/lateral_movement_unusual_remote_file_creation.toml index c0c045fc73e..778d04d6156 100644 --- a/rules/linux/lateral_movement_unusual_remote_file_creation.toml +++ b/rules/linux/lateral_movement_unusual_remote_file_creation.toml @@ -2,7 +2,7 @@ creation_date = "2025/02/20" integration = ["endpoint"] maturity = "production" -updated_date = "2025/02/20" +updated_date = "2025/04/07" [rule] author = ["Elastic"] @@ -17,6 +17,42 @@ index = ["logs-endpoint.events.file*", "auditbeat-*"] language = "kuery" license = "Elastic License v2" name = "Unusual Remote File Creation" +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 Unusual Remote File Creation + +Remote file creation tools like SCP, FTP, and SFTP are essential for transferring files across networks, often used in legitimate administrative tasks. However, adversaries can exploit these services to move laterally within a network, creating files in unauthorized locations. The detection rule identifies suspicious file creation activities by monitoring specific processes and excluding typical paths, thus highlighting potential lateral movement attempts by attackers. + +### Possible investigation steps + +- Review the alert details to identify the specific process name (e.g., scp, ftp, sftp) involved in the file creation event. +- Examine the file path where the file was created to determine if it is an unusual or unauthorized location, considering the exclusion of typical paths like /dev/ptmx, /run/*, or /var/run/*. +- Check the user account associated with the process to verify if it is a legitimate user or if there are signs of compromised credentials. +- Investigate the source and destination IP addresses involved in the file transfer to identify any suspicious or unexpected network connections. +- Analyze recent activity on the host to identify any other unusual or unauthorized actions that may indicate lateral movement or further compromise. +- Correlate this event with other alerts or logs to determine if it is part of a broader attack pattern or campaign within the network. + +### False positive analysis + +- Administrative file transfers: Legitimate administrative tasks often involve transferring files using SCP, FTP, or SFTP. To manage this, create exceptions for known administrative accounts or specific IP addresses that regularly perform these tasks. +- Automated backup processes: Scheduled backups may use tools like rsync or sftp-server to create files remotely. Identify and exclude these processes by specifying the paths or scripts involved in the backup operations. +- System updates and patches: Some system updates might involve remote file creation in non-standard directories. Monitor update schedules and exclude these activities by correlating them with known update events. +- Development and testing environments: Developers may use remote file transfer services to deploy or test applications. Establish a baseline of typical development activities and exclude these from alerts by defining specific user accounts or project directories. +- Third-party integrations: Some third-party applications might require remote file creation as part of their functionality. Document these integrations and exclude their associated processes or file paths from triggering alerts. + +### Response and remediation + +- Isolate the affected host immediately to prevent further lateral movement within the network. This can be done by removing the host from the network or applying network segmentation controls. +- Terminate any suspicious processes identified in the alert, such as scp, ftp, sftp, vsftpd, sftp-server, or sync, to stop unauthorized file transfers. +- Conduct a thorough review of the file paths and files created to determine if any sensitive data has been compromised or if any malicious files have been introduced. +- Restore any unauthorized or malicious file changes from known good backups to ensure system integrity. +- Update and patch the affected systems to close any vulnerabilities that may have been exploited by the attacker. +- Implement stricter access controls and authentication mechanisms for remote file transfer services to prevent unauthorized use. +- Escalate the incident to the security operations center (SOC) or incident response team for further investigation and to determine if additional systems have been compromised. +""" risk_score = 47 rule_id = "ed3fedc3-dd10-45a5-a485-34a8b48cea46" setup = """## Setup @@ -63,6 +99,7 @@ tags = [ "Use Case: Threat Detection", "Tactic: Lateral Movement", "Data Source: Elastic Defend", + "Resources: Investigation Guide", ] timestamp_override = "event.ingested" type = "new_terms" diff --git a/rules/linux/persistence_pth_file_creation.toml b/rules/linux/persistence_pth_file_creation.toml index bdf350753c0..217e73483b5 100644 --- a/rules/linux/persistence_pth_file_creation.toml +++ b/rules/linux/persistence_pth_file_creation.toml @@ -2,7 +2,7 @@ creation_date = "2025/02/26" integration = ["endpoint"] maturity = "production" -updated_date = "2025/02/26" +updated_date = "2025/04/07" [rule] author = ["Elastic"] @@ -18,6 +18,41 @@ index = ["logs-endpoint.events.file*"] language = "eql" license = "Elastic License v2" name = "Python Path File (pth) Creation" +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 Python Path File (pth) Creation + +Python Path Files (.pth) are used to automatically execute code when the Python interpreter starts, making them a potential target for adversaries seeking persistence. Attackers can exploit .pth files by placing malicious code in directories where Python packages reside, ensuring execution each time Python runs. The detection rule monitors the creation and renaming of .pth files in key directories, excluding legitimate processes, to identify unauthorized modifications indicative of malicious activity. + +### Possible investigation steps + +- Review the file path where the .pth file was created or renamed to determine if it is within a legitimate Python package directory, as specified in the query paths. +- Identify the process executable responsible for the creation or renaming of the .pth file and verify if it is listed as an excluded legitimate process in the query. +- Investigate the parent process of the identified executable to understand the context of the .pth file creation and assess if it aligns with expected behavior. +- Check the timestamp of the .pth file creation or renaming event to correlate with any known scheduled tasks or user activities. +- Examine the contents of the .pth file to identify any suspicious or unauthorized code that could indicate malicious intent. +- Review recent system logs and user activity around the time of the event to identify any anomalies or unauthorized access attempts. + +### False positive analysis + +- Legitimate package installations or updates using package managers like pip or poetry can trigger false positives. To handle this, ensure that the process executables for these package managers are included in the exclusion list. +- Automated scripts or CI/CD pipelines that manage Python environments might create or rename .pth files. Identify these scripts and add their executables to the exclusion list to prevent unnecessary alerts. +- System updates or maintenance tasks that involve Python package directories can also result in false positives. Monitor these activities and temporarily adjust the rule or add specific system maintenance processes to the exclusion list. +- Custom Python applications that manage dependencies or configurations through .pth files may cause alerts. Review these applications and consider adding their specific paths or executables to the exclusion criteria. + +### Response and remediation + +- Immediately isolate the affected system from the network to prevent further execution of potentially malicious code. +- Identify and terminate any suspicious processes associated with the creation or modification of .pth files, especially those not matching the legitimate process list. +- Remove any unauthorized .pth files from the identified directories to eliminate the persistence mechanism. +- Conduct a thorough review of recent changes to the Python environment and installed packages to identify any malicious or unauthorized modifications. +- Restore affected systems from a known good backup if malicious activity is confirmed and cannot be fully remediated. +- Escalate the incident to the security operations team for further investigation and to determine if additional systems are affected. +- Implement enhanced monitoring and alerting for future unauthorized .pth file modifications to quickly detect similar threats. +""" references = [ "https://dfir.ch/posts/publish_python_pth_extension/", "https://www.volexity.com/blog/2024/04/12/zero-day-exploitation-of-unauthenticated-remote-code-execution-vulnerability-in-globalprotect-cve-2024-3400/", @@ -57,7 +92,8 @@ tags = [ "Tactic: Persistence", "Tactic: Execution", "Tactic: Defense Evasion", - "Data Source: Elastic Defend" + "Data Source: Elastic Defend", + "Resources: Investigation Guide", ] timestamp_override = "event.ingested" type = "eql" diff --git a/rules/linux/persistence_site_and_user_customize_file_creation.toml b/rules/linux/persistence_site_and_user_customize_file_creation.toml index a84959da147..776f30311ab 100644 --- a/rules/linux/persistence_site_and_user_customize_file_creation.toml +++ b/rules/linux/persistence_site_and_user_customize_file_creation.toml @@ -2,7 +2,7 @@ creation_date = "2025/02/26" integration = ["endpoint"] maturity = "production" -updated_date = "2025/02/26" +updated_date = "2025/04/07" [rule] author = ["Elastic"] @@ -17,6 +17,41 @@ index = ["logs-endpoint.events.file*"] language = "eql" license = "Elastic License v2" name = "Python Site or User Customize File Creation" +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 Python Site or User Customize File Creation + +Python's `sitecustomize.py` and `usercustomize.py` are scripts that execute automatically when Python starts, allowing for environment-specific customizations. Adversaries can exploit these files to maintain persistence by injecting malicious code. The detection rule monitors file creation and modification in key directories, excluding benign processes, to identify unauthorized changes indicative of potential backdooring or persistence attempts. + +### Possible investigation steps + +- Review the file path where the creation or modification was detected to determine if it is a system-wide, user-specific, or virtual environment location, as specified in the query. +- Identify the process executable responsible for the file creation or modification and verify if it is listed in the exclusion list of benign processes. If not, investigate the process for potential malicious activity. +- Check the timestamp of the file creation or modification event to correlate with any other suspicious activities or alerts on the system around the same time. +- Examine the contents of the sitecustomize.py or usercustomize.py file for any unauthorized or suspicious code that could indicate persistence mechanisms or backdooring attempts. +- Investigate the user account associated with the file creation or modification event to determine if the activity aligns with expected behavior or if it suggests potential compromise. +- Review system logs and other security alerts for additional context or indicators of compromise related to the detected event. + +### False positive analysis + +- Package managers like pip and poetry can trigger false positives when they create or modify sitecustomize.py or usercustomize.py during package installations or updates. To handle this, ensure these processes are included in the exclusion list within the detection rule. +- System updates or software installations that involve Python libraries might also lead to false positives. Regularly review and update the exclusion list to include known benign processes such as pacman or restic that are part of routine system maintenance. +- Custom scripts or automation tools that use Python to manage environments could inadvertently modify these files. Identify and exclude these specific scripts or tools if they are verified as non-malicious. +- Virtual environments often involve the creation of sitecustomize.py for environment-specific configurations. Consider excluding the virtual environment's Python executables if they are part of a controlled and secure development process. + +### Response and remediation + +- Isolate the affected system from the network to prevent further unauthorized access or spread of malicious code. +- Review the contents of the `sitecustomize.py` and `usercustomize.py` files for any unauthorized or suspicious code. Remove any malicious code identified. +- Restore the affected files from a known good backup if available, ensuring that the restored files are free from unauthorized modifications. +- Conduct a thorough scan of the system using updated antivirus or endpoint detection and response (EDR) tools to identify and remove any additional malware or persistence mechanisms. +- Monitor the system and network for any signs of continued unauthorized access or attempts to modify the `sitecustomize.py` and `usercustomize.py` files. +- Escalate the incident to the security operations center (SOC) or incident response team for further investigation and to determine if additional systems are affected. +- Implement additional monitoring and alerting for changes to critical Python directories and files to enhance detection of similar threats in the future. +""" risk_score = 21 rule_id = "d788313c-9e0b-4c5a-8c4b-c3f05a47d5a8" setup = """## Setup @@ -52,7 +87,8 @@ tags = [ "Tactic: Persistence", "Tactic: Execution", "Tactic: Defense Evasion", - "Data Source: Elastic Defend" + "Data Source: Elastic Defend", + "Resources: Investigation Guide", ] timestamp_override = "event.ingested" type = "eql" diff --git a/rules/linux/persistence_user_credential_modification_via_echo.toml b/rules/linux/persistence_user_credential_modification_via_echo.toml index 472624def9b..60dd97ca1e7 100644 --- a/rules/linux/persistence_user_credential_modification_via_echo.toml +++ b/rules/linux/persistence_user_credential_modification_via_echo.toml @@ -2,7 +2,7 @@ creation_date = "2025/02/21" integration = ["endpoint"] maturity = "production" -updated_date = "2025/02/21" +updated_date = "2025/04/07" [rule] author = ["Elastic"] @@ -16,6 +16,41 @@ index = ["logs-endpoint.events.process*"] language = "eql" license = "Elastic License v2" name = "Linux User Account 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 Linux User Account Credential Modification + +In Linux environments, user account credentials are crucial for system access and management. Adversaries may exploit command-line utilities to modify credentials, often using scripts to automate this process post-infection. The detection rule identifies suspicious use of shell commands that echo passwords into the passwd utility, a technique indicative of unauthorized credential changes, by monitoring specific command patterns and excluding benign processes. + +### Possible investigation steps + +- Review the process command line to confirm the presence of the suspicious pattern "*echo*passwd*" and assess if it aligns with known malicious activity. +- Identify the user account associated with the process to determine if it is a legitimate user or potentially compromised. +- Examine the parent process details, including the command line and executable path, to understand the context of how the suspicious process was initiated. +- Check for any recent changes to user accounts on the system, focusing on password modifications or new account creations around the time of the alert. +- Investigate the system for any additional signs of compromise, such as unexpected network connections or other suspicious processes running concurrently. +- Correlate the event with other security alerts or logs to identify if this activity is part of a broader attack pattern or campaign. + +### False positive analysis + +- Automated build processes may trigger this rule if they use shell scripts that include echoing passwords for testing or configuration purposes. To handle this, exclude processes with parent command lines or executables related to build tools like make. +- System administration scripts that automate user account management might use similar command patterns. Review these scripts and exclude them by specifying their parent process or executable paths. +- Custom user scripts for password management could inadvertently match the rule's criteria. Identify these scripts and add exceptions based on their unique command line or parent process attributes. +- Some legitimate software installations might use echo and passwd in their setup scripts. Monitor installation logs and exclude known safe installation processes by their parent command line or executable. + +### Response and remediation + +- Immediately isolate the affected Linux system from the network to prevent further unauthorized access or lateral movement by the adversary. +- Terminate any suspicious processes identified by the detection rule, particularly those involving the echo command being used with the passwd utility. +- Change the passwords of any user accounts that may have been compromised, ensuring the use of strong, unique passwords. +- Review and audit recent user account changes and access logs to identify any unauthorized modifications or access attempts. +- Restore any affected user accounts to their previous state using backups or system snapshots, if available. +- Escalate the incident to the security operations team for further investigation and to determine if additional systems are affected. +- Implement additional monitoring and alerting for similar command patterns to enhance detection and prevent recurrence of this threat. +""" risk_score = 21 rule_id = "79e7291f-9e3b-4a4b-9823-800daa89c8f9" setup = """## Setup @@ -45,7 +80,8 @@ tags = [ "OS: Linux", "Use Case: Threat Detection", "Tactic: Persistence", - "Data Source: Elastic Defend" + "Data Source: Elastic Defend", + "Resources: Investigation Guide", ] timestamp_override = "event.ingested" type = "eql" diff --git a/rules/linux/persistence_web_server_sus_child_spawned.toml b/rules/linux/persistence_web_server_sus_child_spawned.toml index 04c5e46c928..6f6761906dc 100644 --- a/rules/linux/persistence_web_server_sus_child_spawned.toml +++ b/rules/linux/persistence_web_server_sus_child_spawned.toml @@ -2,7 +2,7 @@ creation_date = "2025/03/04" integration = ["endpoint"] maturity = "production" -updated_date = "2025/04/03" +updated_date = "2025/04/07" [rule] author = ["Elastic"] @@ -18,6 +18,42 @@ interval = "1h" language = "esql" license = "Elastic License v2" name = "Unusual Process Spawned from Web Server Parent" +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 Unusual Process Spawned from Web Server Parent + +Web servers like Apache, Nginx, and others are crucial for hosting applications and services. Adversaries exploit these servers by spawning unauthorized processes to maintain persistence or execute malicious commands. The detection rule identifies anomalies by monitoring low-frequency process spawns from web server parents, focusing on unusual user IDs, directories, and process counts, which may indicate potential threats. + +### Possible investigation steps + +- Review the process.executable and process.command_line fields to understand the nature of the process that was spawned and assess if it aligns with expected behavior for the web server environment. +- Examine the process.working_directory to determine if the directory is a legitimate location for web server operations or if it appears suspicious, such as being outside typical web server directories. +- Check the user.name and user.id fields to verify if the process was executed by a legitimate web server user or if it was initiated by an unexpected or unauthorized user account. +- Investigate the process.parent.executable to confirm whether the parent process is a known and trusted web server executable or if it has been tampered with or replaced. +- Correlate the event with other logs or alerts from the same agent.id to identify any additional suspicious activities or patterns that may indicate a broader compromise. +- Assess the host.os.type to ensure the alert pertains to a Linux system, as specified in the query, and verify if there are any known vulnerabilities or misconfigurations on the host that could have been exploited. + +### False positive analysis + +- Processes related to legitimate web server maintenance tasks may trigger alerts. Review scheduled tasks or cron jobs that align with the alert timing and consider excluding these specific processes if they are verified as non-threatening. +- Development environments often spawn processes that mimic attack patterns. Identify and exclude processes originating from known development directories or executed by development user accounts. +- Automated scripts or monitoring tools running under web server user accounts can be mistaken for malicious activity. Verify these scripts and add exceptions for their specific process names or working directories. +- Frequent updates or deployments in web applications can lead to unusual process spawns. Document these activities and exclude related processes if they consistently match the alert criteria during known update windows. +- Custom web server modules or plugins may execute processes that appear suspicious. Validate these modules and exclude their associated processes if they are part of normal operations. + +### Response and remediation + +- Immediately isolate the affected host from the network to prevent further malicious activity and potential lateral movement. +- Terminate any suspicious processes identified by the alert that are not part of legitimate web server operations. +- Conduct a thorough review of the process command lines and executables flagged by the alert to identify any malicious scripts or binaries. Remove or quarantine these files as necessary. +- Check for unauthorized changes in web server configurations or files within the working directories flagged by the alert. Restore any altered files from a known good backup. +- Review user accounts and permissions associated with the web server processes to ensure no unauthorized accounts or privilege escalations have occurred. Reset passwords and revoke unnecessary access. +- Monitor network traffic from the affected host for any signs of command and control communication, and block any identified malicious IP addresses or domains. +- Escalate the incident to the security operations center (SOC) or incident response team for further analysis and to determine if additional systems are compromised. +""" risk_score = 47 rule_id = "976b2391-413f-4a94-acb4-7911f3803346" setup = """## Setup @@ -54,6 +90,7 @@ tags = [ "Tactic: Execution", "Tactic: Command and Control", "Data Source: Elastic Defend", + "Resources: Investigation Guide", ] timestamp_override = "event.ingested" type = "esql" diff --git a/rules/linux/persistence_web_server_sus_command_execution.toml b/rules/linux/persistence_web_server_sus_command_execution.toml index 7dc86be2503..604bb77bc5c 100644 --- a/rules/linux/persistence_web_server_sus_command_execution.toml +++ b/rules/linux/persistence_web_server_sus_command_execution.toml @@ -2,7 +2,7 @@ creation_date = "2025/03/04" integration = ["endpoint"] maturity = "production" -updated_date = "2025/04/03" +updated_date = "2025/04/07" [rule] author = ["Elastic"] @@ -19,6 +19,48 @@ interval = "1h" language = "esql" license = "Elastic License v2" name = "Unusual Command Execution from Web Server Parent" +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 Unusual Command Execution from Web Server Parent + +Web servers, such as Apache or Nginx, are crucial for hosting web applications, often running on Linux systems. Adversaries exploit vulnerabilities in these servers to execute arbitrary commands, typically through web shells, blending malicious activity with legitimate server processes. The detection rule identifies suspicious command executions originating from web server processes, focusing on unusual patterns and contexts, such as unexpected working directories or command structures, to flag potential compromises. + +### Possible investigation steps + +- Review the process.command_line field to understand the specific command executed and assess its legitimacy or potential malicious intent. +- Examine the process.working_directory to determine if the command was executed from an unusual or suspicious directory, which could indicate a compromise. +- Check the process.parent.executable and process.parent.name fields to identify the parent process and verify if it is a known web server or related service that could be exploited. +- Investigate the user.name and user.id fields to confirm if the command was executed by a legitimate user or service account, or if it was potentially executed by an unauthorized user. +- Correlate the @timestamp with other logs and events to identify any related activities or anomalies occurring around the same time, which could provide additional context or evidence of an attack. +- Assess the agent.id to determine if the alert is isolated to a single host or if similar activities are observed across multiple hosts, indicating a broader issue. + +### False positive analysis + +- Web development or testing environments may frequently execute commands from web server processes. To handle this, exclude specific working directories like /var/www/dev or /var/www/test from the rule. +- Automated scripts or cron jobs running under web server user accounts can trigger alerts. Identify these scripts and add exceptions for their specific command lines or user IDs. +- Legitimate administrative tasks performed by web server administrators might appear suspicious. Document these tasks and exclude their associated command lines or parent executables. +- Continuous integration or deployment processes that involve web server interactions can be mistaken for threats. Exclude known CI/CD tool command lines or working directories from the rule. +- Monitoring or logging tools that interact with web server processes may generate false positives. Identify these tools and exclude their specific process names or parent executables. + +### Response and remediation + +- Isolate the affected host immediately to prevent further malicious activity and lateral movement within the network. This can be done by removing the host from the network or applying network segmentation. + +- Terminate any suspicious processes identified by the detection rule, especially those originating from web server parent processes executing shell commands. Use process IDs and command lines from the alert to target specific processes. + +- Conduct a thorough review of the web server logs and application logs to identify any unauthorized access or modifications. Look for patterns that match the command execution detected and any other anomalies. + +- Patch the web server and any associated applications to address known vulnerabilities that may have been exploited. Ensure that all software is up to date with the latest security patches. + +- Restore the affected system from a known good backup if any unauthorized changes or persistent threats are detected. Ensure that the backup is free from compromise before restoration. + +- Implement additional monitoring and alerting for similar activities, focusing on unusual command executions and web server behavior. Enhance logging and alerting to capture more detailed information about process executions and network connections. + +- Escalate the incident to the security operations center (SOC) or incident response team for further investigation and to determine if the attack is part of a larger campaign. Provide them with all relevant data and findings from the initial containment and remediation steps. +""" risk_score = 47 rule_id = "8a7933b4-9d0a-4c1c-bda5-e39fb045ff1d" setup = """## Setup @@ -55,6 +97,7 @@ tags = [ "Tactic: Execution", "Tactic: Command and Control", "Data Source: Elastic Defend", + "Resources: Investigation Guide", ] timestamp_override = "event.ingested" type = "esql" diff --git a/rules/linux/persistence_web_server_sus_destination_port.toml b/rules/linux/persistence_web_server_sus_destination_port.toml index 39815bc2df6..9755dbd1e44 100644 --- a/rules/linux/persistence_web_server_sus_destination_port.toml +++ b/rules/linux/persistence_web_server_sus_destination_port.toml @@ -2,7 +2,7 @@ creation_date = "2025/03/05" integration = ["endpoint"] maturity = "production" -updated_date = "2025/03/05" +updated_date = "2025/04/07" [rule] author = ["Elastic"] @@ -16,6 +16,42 @@ index = ["logs-endpoint.events.network*"] language = "eql" license = "Elastic License v2" name = "Uncommon Destination Port Connection by Web Server" +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 Uncommon Destination Port Connection by Web Server + +Web servers, crucial for hosting applications, typically communicate over standard ports like 80 and 443. Adversaries may exploit web server processes to establish unauthorized connections to unusual ports, potentially indicating web shell activity or data exfiltration. This detection rule identifies such anomalies by monitoring egress connections from web server processes to non-standard ports, excluding common local IP ranges, thus highlighting potential threats. + +### Possible investigation steps + +- Review the process name and user associated with the alert to determine if the connection attempt was made by a legitimate web server process or user, as specified in the query fields (e.g., process.name or user.name). +- Examine the destination IP address to assess whether it is known or suspicious, and check if it falls outside the excluded local IP ranges. +- Investigate the destination port to understand why the connection was attempted on a non-standard port, and determine if this port is associated with any known services or threats. +- Check historical logs for any previous connection attempts from the same process or user to the same or similar destination IPs and ports to identify patterns or repeated behavior. +- Analyze any related network traffic or logs to identify additional context or anomalies that may indicate unauthorized activity or data exfiltration. +- Correlate the alert with other security events or alerts to determine if it is part of a larger attack pattern or campaign. + +### False positive analysis + +- Routine administrative tasks or maintenance scripts may trigger alerts if they involve web server processes connecting to non-standard ports. To manage this, identify and document these tasks, then create exceptions for the specific processes and ports involved. +- Internal monitoring or management tools that use non-standard ports for legitimate purposes can cause false positives. Review the tools in use and exclude their known IP addresses and ports from the rule. +- Development or testing environments often use non-standard ports for web server processes. Ensure these environments are well-documented and consider excluding their IP ranges or specific ports from the rule. +- Load balancers or reverse proxies might redirect traffic to non-standard ports as part of their normal operation. Verify the configuration of these devices and exclude their IP addresses and ports if necessary. +- Custom applications running on web servers may require communication over non-standard ports. Work with application owners to understand these requirements and adjust the rule to exclude these specific cases. + +### Response and remediation + +- Immediately isolate the affected web server from the network to prevent further unauthorized access or data exfiltration. +- Conduct a thorough review of the web server's logs and processes to identify any unauthorized changes or suspicious activities, focusing on the processes and user accounts mentioned in the detection rule. +- Terminate any suspicious processes identified during the investigation that are not part of the standard operation of the web server. +- Change passwords and review permissions for the user accounts associated with the web server processes to ensure they have not been compromised. +- Restore the web server from a known good backup if any unauthorized changes or malware are detected, ensuring that the backup is free from compromise. +- Implement network segmentation to limit the web server's access to critical systems and data, reducing the potential impact of future incidents. +- Escalate the incident to the security operations team for further analysis and to determine if additional systems may be affected, ensuring comprehensive threat containment and remediation. +""" risk_score = 21 rule_id = "00546494-5bb0-49d6-9220-5f3b4c12f26a" setup = """## Setup @@ -52,6 +88,7 @@ tags = [ "Tactic: Execution", "Tactic: Command and Control", "Data Source: Elastic Defend", + "Resources: Investigation Guide", ] timestamp_override = "event.ingested" type = "eql" diff --git a/rules/macos/command_and_control_unusual_connection_to_suspicious_top_level_domain.toml b/rules/macos/command_and_control_unusual_connection_to_suspicious_top_level_domain.toml index f95ebb70fc3..cd1e4aa5a67 100644 --- a/rules/macos/command_and_control_unusual_connection_to_suspicious_top_level_domain.toml +++ b/rules/macos/command_and_control_unusual_connection_to_suspicious_top_level_domain.toml @@ -2,7 +2,7 @@ creation_date = "2025/03/25" integration = ["endpoint"] maturity = "production" -updated_date = "2025/03/25" +updated_date = "2025/04/07" [rule] author = ["Elastic"] @@ -14,6 +14,42 @@ index = ["logs-endpoint.events.network-*"] language = "kuery" license = "Elastic License v2" name = "Unusual Network Connection to Suspicious Top Level Domain" +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 Unusual Network Connection to Suspicious Top Level Domain + +In macOS environments, network connections are essential for communication and data exchange. Adversaries exploit this by connecting to suspicious top-level domains (TLDs) for command and control activities. The detection rule identifies unusual outbound connections to these TLDs, signaling potential threats. By monitoring specific domains, it helps detect and mitigate malicious activities early. + +### Possible investigation steps + +- Review the destination domain involved in the alert to determine if it is associated with known malicious activities or if it has been flagged in threat intelligence databases. +- Analyze the network traffic details related to the connection, including the source IP address and the volume of data transferred, to assess the nature and intent of the communication. +- Check the host system's recent activity logs for any unusual processes or applications that initiated the network connection, focusing on the event.type "start" to identify the triggering process. +- Investigate the user account associated with the host to determine if there have been any unauthorized access attempts or anomalies in user behavior. +- Correlate the alert with other security events or alerts from the same host or network segment to identify potential patterns or coordinated activities. +- Consult with threat intelligence sources or security forums to gather additional context on the specific top-level domain and its potential use in command and control operations. + +### False positive analysis + +- Legitimate business domains may use TLDs like .online or .store for marketing purposes. Review the domain's reputation and business context before marking it as a threat. +- Personal or small business websites might use TLDs such as .fun or .life. Verify the domain ownership and usage to determine if it is a false positive. +- Some educational or community projects might use TLDs like .club or .space. Check the domain's content and purpose to assess its legitimacy. +- Exclude known safe domains by adding them to an allowlist in your monitoring tool to prevent repeated false positives. +- Regularly update the allowlist based on user feedback and network behavior analysis to ensure it remains accurate and effective. + +### Response and remediation + +- Immediately isolate the affected macOS device from the network to prevent further communication with the suspicious domain. +- Conduct a thorough review of the network logs to identify any additional devices that may have communicated with the same suspicious domains and isolate them if necessary. +- Use endpoint security tools to perform a full malware scan on the affected device to identify and remove any malicious software. +- Reset credentials and review access permissions for any accounts that were active on the affected device to prevent unauthorized access. +- Escalate the incident to the security operations center (SOC) or incident response team for further analysis and to determine if the threat is part of a larger attack campaign. +- Implement network-level blocking of the identified suspicious domains to prevent future connections from any device within the network. +- Review and update firewall and intrusion detection/prevention system (IDS/IPS) rules to enhance detection and blocking of similar threats in the future. +""" risk_score = 47 rule_id = "ffa676dc-09b0-11f0-94ba-b66272739ecb" severity = "medium" @@ -22,7 +58,8 @@ tags = [ "OS: macOS", "Use Case: Threat Detection", "Tactic: Command and Control", - "Data Source: Elastic Defend" + "Data Source: Elastic Defend", + "Resources: Investigation Guide", ] timestamp_override = "event.ingested" type = "new_terms" diff --git a/rules/macos/command_and_control_unusual_network_connection_to_suspicious_web_service.toml b/rules/macos/command_and_control_unusual_network_connection_to_suspicious_web_service.toml index 2791652a881..8da64a145eb 100644 --- a/rules/macos/command_and_control_unusual_network_connection_to_suspicious_web_service.toml +++ b/rules/macos/command_and_control_unusual_network_connection_to_suspicious_web_service.toml @@ -2,7 +2,7 @@ creation_date = "2025/03/26" integration = ["endpoint"] maturity = "production" -updated_date = "2025/03/26" +updated_date = "2025/04/07" [rule] author = ["Elastic"] @@ -14,6 +14,42 @@ index = ["logs-endpoint.events.network-*"] language = "kuery" license = "Elastic License v2" name = "Unusual Network Connection to Suspicious Web 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 Unusual Network Connection to Suspicious Web Service + +In macOS environments, network connections to web services are routine for data sharing and collaboration. However, adversaries exploit these services for command and control by disguising malicious traffic as legitimate. The detection rule identifies unusual outbound connections to known suspicious domains, flagging potential misuse by monitoring specific domain patterns and connection events, thus aiding in early threat detection. + +### Possible investigation steps + +- Review the destination domain and process executable from the alert to determine if it matches any expected web service communication. +- Check the event.category and event.type fields to confirm the nature of the network connection and ensure it aligns with the expected behavior of a macOS system. +- Investigate the source host identified by host.os.type to gather information about its recent activities, installed applications, and any potential indicators of compromise. +- Analyze network traffic logs for the source host to identify any other unusual or suspicious outbound connections that may indicate a broader compromise. +- Correlate the alert with other security events or alerts from the same host or network segment to identify patterns or related incidents. +- Consult threat intelligence sources to gather additional context on the flagged domain and assess its reputation and history of malicious activity. + +### False positive analysis + +- Frequent access to legitimate cloud storage services like Google Drive or Dropbox for routine file sharing can trigger false positives. Users can create exceptions for specific domains or IP addresses known to be safe and frequently accessed by their organization. +- Automated backup services that use domains such as OneDrive or SharePoint may be flagged. To mitigate this, identify and whitelist the specific services or applications that are part of regular backup operations. +- Collaboration tools like Slack or Discord, used for legitimate communication, might be mistakenly flagged. Users should review and whitelist these domains if they are part of standard business operations. +- URL shorteners like bit.ly or tinyurl.com used in marketing or communication campaigns can cause false alerts. Establish a list of trusted shortener services and exclude them from monitoring if they are regularly used by the organization. +- Development and testing environments using services like ngrok or localtunnel for temporary public URLs can be misidentified. Ensure these environments are documented and excluded from the rule if they are part of normal development workflows. + +### Response and remediation + +- Immediately isolate the affected macOS device from the network to prevent further communication with the suspicious domains. +- Conduct a thorough review of the network logs to identify any data exfiltration attempts or additional suspicious connections originating from the isolated device. +- Remove any unauthorized or suspicious applications or scripts found on the device that may be facilitating the outbound connections. +- Update the device's security software and perform a full system scan to detect and remove any malware or unauthorized software. +- Reset credentials and review access permissions for the affected user accounts to prevent unauthorized access. +- Monitor the network for any further attempts to connect to the flagged domains and ensure that alerts are configured to notify security teams of any recurrence. +- Escalate the incident to the security operations center (SOC) or relevant cybersecurity team for further investigation and to determine if the threat is part of a larger attack campaign. +""" risk_score = 47 rule_id = "b07f0fba-0a78-11f0-8311-b66272739ecb" severity = "medium" @@ -22,7 +58,8 @@ tags = [ "OS: macOS", "Use Case: Threat Detection", "Tactic: Command and Control", - "Data Source: Elastic Defend" + "Data Source: Elastic Defend", + "Resources: Investigation Guide", ] timestamp_override = "event.ingested" type = "new_terms"